Re: [FFmpeg-devel] rebasing security

[Michael Niedermayer <michael@niedermayer.cc>]

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

Hi

On Wed, Aug 06, 2025 at 08:51:01AM +0200, Alexander Strasser via ffmpeg-devel wrote:
> On 2025-08-06 00:37 +0200, Michael Niedermayer wrote:
> > 
> > On Mon, Aug 04, 2025 at 10:15:53PM +0200, Alexander Strasser via ffmpeg-devel wrote:
> [...]
> > > 
> > > If I understand the original point you wanted to discuss correctly,
> > > than this is not a question of rebase or merge but one of letting
> > > **commits happen on the forge**. If it happens it bears the
> > > possibility of modification on the server the forge is running on.
> > 
> > It is a question of rebase vs merge because
> > if the forge generates a merge A+B and lets assume it tampers with it
> > this is trivially detectable from nothing than just the git checkout
> > 
> > To detect it:
> > just redo every merge that is not signed or that is signed by the forgejo key
> > the tree after it, either matches or it was very likely tampered with
> 
> That would require to redo each merge commit with exact meta.
> If you only compare the tree contents, that wouldn't be necessary but is
> a good bit less secure.

more checking, is better, yes


> 
> 
> > With rebases, detection is possible but more complex
> > First you need not just the git checkout but every single pull request
> > and exactly the last pushed one before the rebase and they need to have been
> > signed.
> > Then you can redo all the rebases and verify that they have not been tampered with
> > 
> > With the merge case the last pull requests are part of the git checkout and
> > signing is not critical because when something is part of a git checkout
> > its just hard to tamper with it, the author might notice it mismatches
> 
> I agree it's easier to check with merges, but it doesn't sound like
> something usual people would do. So would mostly only be relevant if
> we set up something to double check.
> 
> 
> IMHO we should not right now discuss and possibly change
> workflow / branching model of FFmpeg. Right now we have enough in limbo,
> so changing this too might be a bit too much at a time.
> 
> As you already mentioned there are other advantages to merging, so
> it might make sense to bring it up again at some point.

as long as the people take responsibility for their decission, iam perfectly
fine with it.

I just like to make it clear that the "on server rebase with no verification"
is a community choice, not my choice.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 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".