Re: Next steps from GTI TAC meeting on 2023-03-08 - Evaluate cost of glibc migration.

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Wed, May 24, 2023 at 02:13:53PM -0400, Siddhesh Poyarekar wrote:
> It looks like the question of who to ultimately trust, either the gatekeeper
> committer (or two) who is the only person to have write access to the
> repository, or the admin who manages the box.

The maintainer's action are in the public, while the admin's actions are
hidden.

> The gatekeeper committer could also fabricate commits and push to the
> central repository in the same way.

1. Not with nearly as much impunity, especially if non-fast-forward pushes are
   disallowed. 
2. At best, a maintainer can modify someone's patch to introduce a deliberate
   bug, not freely modify a commit somewhere in recent history to add
   significant chunks of code like an admin can.
3. If it's someone else's code they are committing, the original developer
   will probably discover any malicious edits, because they will be watching
   their own commits show up in the repository.
4. It's much easier to audit and review the actions of 2-3 co-maintainers than
   when hundreds of people have write access to the repository.
5. When only a small subset of people can push to a repository, maintaining a
   valid keyring for verifying their cryptographic signatures is much easier
   than when 400+ people all have write access.

I could go on for quite a while still. My recent talk at the Linux Security
Summit was on the subject of how easy it would be to sneak a backdoor into the
Linux kernel where I go into many of these considerations (unfortunately, the
talk not yet posted on the LF channel).

> In fact, the gatekeeper committer could choose to do worse, like
> delaying (or declining to merge) someones patches.

The gatekeeper is accountable to the community and can be replaced. The
admin's actions may never be discovered or they can be blamed on someone else.

-K