Re: [FFmpeg-devel] rebasing security

[Timo Rothenpieler <timo@rothenpieler.org>]

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

On 8/3/2025 10:29 PM, Michael Niedermayer wrote:
> Hi Timo
> 
> On Sun, Aug 03, 2025 at 10:01:42PM +0200, Timo Rothenpieler wrote:
>> 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.
> 
> yes
> 
> 
>>
>> I can configure Forgejo to sign commits it itself generates, that is an
>> option.
> 
> is there a disadvantage ?
> 
> 
>> See here for how it can do it on merges.
>> https://forgejo.org/docs/latest/admin/advanced/signing/#pull-request-merges
> 
> confusing, so many options
> 
> 
>>
>> 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.
> 
> yeah, I have not thought deeply about it, they seem to want to indicate
> something by signing commmits.
> 
> To me signing my commits primarly is a way to say the commit was not tampered
> with after I signed it.

I'll add a key to the instance and enable it in commitssigned mode for 
now. That seems to be the most conservative option for a start.

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