Free software developer

  • 0 Posts
  • 7 Comments
Joined 1 year ago
cake
Cake day: June 30th, 2023

help-circle


  • It’s not a responsibly of the format, so, at most, it’s a mere side effect. In any practical process which could result with truncated data, even if it handles data with such property, it should be wrapped in a container which includes length. At the very least, it would allow to trace the source of truncation, e.g. was the data originally truncated, or was it truncated in the process, and change the format without shooting in oneselves foot. And the generating side should always provide success flag which should be properly handled, since it may produce syntactically correct, but semantically invalid data. Such as checking exit code of process which generates json/yaml in question




  • AMDmi3@lemmy.worldtoProgramming@programming.devUnsigned Commits
    link
    fedilink
    arrow-up
    7
    arrow-down
    2
    ·
    10 months ago

    Agreed, and I have more arguments against commit signing.

    • Commit immutability is undesirable, and mutable commits are not compatible with signing. For instance, pull requests are squashed and rebased to keep linear history, and changes are cherry picked around. It does not change authorship, however it changes hashes and invalidates any signatures. Or, say, one wants to adopt an otherwise FOSS project which though contains some copyrighted material in its repository, which needs to be filter-branched away, again invalidating the signatures.
    • In our world where stuff randomly gets criminalized I prefer to avoid being undeniably linked to my code.

    BTW this topic has common considerations with now mandatory (on GH and more places) 2FA. For the latter reason, and also for own convenience and for reducing risk of losing access to your account (which I assess as much higher than risk of leaking my password to third parties) I make second factor public, effectively reverting to 1FA.