Re: [FFmpeg-devel] rebasing security

[Timo Rothenpieler <timo@rothenpieler.org>]

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

On 8/3/2025 9:02 PM, Michael Niedermayer wrote:
> Hi
> 
> On Sun, Aug 03, 2025 at 05:31:39PM +0200, Michael Niedermayer wrote:
> [...]
>> The solutions are obvious:
>> 1. ignore security and supply chain attacks
>> 2. use merges not rebases on the server
>> 3. rebase locally, use fast forward only
>> 4. verify on server rebases
> 
> Maybe not everyone understood the problem. So let me try a different
> explanation. Without any signatures.
> 
> In the ML workflow: (for simplicity we assume reviewer and commiter is the same person)
> 1. someone posts a patch
> 2. patch is locally applied or rebased
> 3. commit is reviewed
> 4. commit is tested
> 5. commit is pushed
> 
> Here the only way to get bad code in, is through the reviewer
> If the reviewer doesnt miss anything and his setup is not compromised
> then what he pushes is teh reviewed code
> 
> if its manipulated after its pushed git should light up like a christmess tree
> on the next "git pull --rebase"
> 
> 
> With the rebase on webapp (gitlab or forgejo) workflow
> 1. someone posts a pull request
> 2. pr is reviewed
> 3. pr is approved
> 4. pr is rebased
> 5. pr is tested
> 6, pr is pushed
> 
> now here of course the same reviewer trust or compromised scenarios exist
> but we also have an extra one and that is the server
> because the server strips the signatures during rebase it can modify the
> commit. And this happens after review and because a rebase was litterally
> requested by the reviewer its not likely to be noticed as something out of
> place
If you as a pusher of commits want to sign them with your own key, you 
have to do that manually.
There is no sane way for Forgjo to do that for you.

I can configure Forgejo to sign commits it itself generates, that is an 
option. See here for how it can do it on merges.
https://forgejo.org/docs/latest/admin/advanced/signing/#pull-request-merges

I think if I set it to "commitssigned", it'll check all commits in the 
PR against the users configured GPG/SSH key, and if they are all valid, 
it'll then sign them with the instance key whenever it needs to modify 
them for an operation.
"twofa" would also be an option, cause it indicates that the author of 
that commit has some reasonably strong proof that they are them themselves.

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4742 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".