Re: [FFmpeg-devel] [RFC] git and signing commits and tags

[Gerion Entrup <gerion.entrup@flump.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2730 bytes --]

Hi,

Am Montag, 8. August 2022, 21:26:52 CEST schrieb Lynne:
> Aug 8, 2022, 16:50 by michael@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-request@ffmpeg.org with subject "unsubscribe".
> 


[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".