Hi, Am Montag, 8. August 2022, 21:26:52 CEST schrieb Lynne: > Aug 8, 2022, 16:50 by mich...@niedermayer.cc: > > > Given the recent server issues, i wonder if we should suggest/recommand > > and document signing commits and tags > > > > i tried to push such commit to github and it nicely says "verified" > > https://github.com/michaelni/FFmpeg/commit/75f196acd16fb0c0ca7a94f0c66072e7c6f736bf > > > > Ive generated a new gpg key for this experiment as i dont have my > > main key on the box used for git development and also using more > > modern eliptic curve stuff (smaller keys & sigs) > > i will upload this key to the keyservers in case it becomes the > > one i use for git. > > > > I sign all of my commits, I think it should be recommended but > not required. > > One downside is that you can sign commits from others with your > own key (for instance when pushing a patch from someone along > with your commits, and signing all at once via rebase), which can be > misleading, so it takes some work to reorder commits or push them > in stages so this doesn't happen. It makes sense that it's the > committer who's signing it, but git or github don't make a distinction > when it comes to signing.
Since Git is kind of a blockchain (it includes the hash of the predecessor commits) you technically sign the entire tree anyways not just the individual commit. Especially in a rebase, the original author signs the original commit hash (which changes in a rebase), so it is not possible to use the same signature again. But I understand that a direct mapping between author and singing person would be nice. For releases, I think that the attacker model is important. The typical scenario is that one clones the repository, than checkouts a tag and compiles FFmpeg. For that one wants to know that the code is not manipulated by a third party (a person not trusted by the FFmpeg project). If the last commit is signed then, the user know that they can trust the entire code. If they checkout a random commit that is not signed, they cannot be sure that the set of changes up to the next signed commit of an FFmpeg author comes from a person trusted by FFmpeg. But for that it doesn't matter which of the devs has signed the commit. So I think for end users a signed release commit is most valuable, individual commits are valuable, too, and it's important that the signature must always come from a person trusted by the FFmpeg project. Best, Gerion > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
