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


thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus