Approval does not give any guarantee.  Anyone can impersonate someone else,
it’s just about changing the author in your git config.
If we want a bit more guarantee, we need to require signed commits.


------------------------
Guillaume Nodet


Le sam. 16 mai 2026 à 14:02, Elliotte Rusty Harold <[email protected]> a
écrit :

> On Fri, May 15, 2026 at 2:41 PM Slawomir Jaranowski
> <[email protected]> wrote:
> >
> > Hi,
> >
> > From me also -1
> >
> > Agree with Tamás
> >
> > and more:
> >  - release process and tool are not ready - if I'm misses about it,
> > please try do release first in new way without write to default
> > branch, next we can talk
>
> Legitimate, but if this is a blocker we need to fix this. We can
> deprioritize other work if necessary to move the release tool forward.
>
> >  - I can create a fake account on on GitHub and switching between it -
> > one for create PR and one for approve
>
> No, I don't think you can. You'd need another committer account to
> approve. If that's not true and any account can approve, then we need
> to fix that.
>
> >  - we have a vote process where artifact and commits are checked
> > before publishing
> >  - you can check reproducible build during vote
>
> That doesn't help at all. It just proves the malicious commit is
> reproducible.
>
> >  - we have protected branches so force push with history override is
> disabled,
> >  - all commits are logged on public ML
>
> Necessary but not sufficient. We need defense in depth. This is only
> one of several mitigations we need to take.
>
> --
> Elliotte Rusty Harold
> [email protected]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to