[FFmpeg-devel] rebasing security

[Alexander Strasser]

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.


> 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.


  Alexander