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

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Tue, May 23, 2023 at 10:12:20PM +0000, Joseph Myers wrote:
> > Can you please describe the lifecycle of a patch and how it gets from "user
> > sends a change to the mailing list" to "that patch becomes a commit in the
> > official project repository where it lives forever."
> 
> A patch is sent to the list.  There are some number of review / revision 
> rounds, ending with a reviewer or maintainer saying it is OK to commit (or 
> OK after some specified changes, or OK in the absence of objections within 
> some given period, etc.).  If the person posting the patch has commit 
> access, they commit it; otherwise they should ask the maintainer to do so 
> for them.  Maintainers of parts of the compiler may commit their patches 
> without someone else reviewing them.

This workflow has one important problem -- you must ultimately trust the
integrity of your infrastructure. It would be very easy for a malicious actor
with access to backend infrastructure to insert a commit into the repository
without it being discovered:

1. they can override any server-side validations
2. they can disable email notifications
3. they can forge the Committer identity of the commit

With your current workflow nobody would find out that such commit has been
inserted into the history because everyone must rebase their commits anyway,
so having a push rejected due to newer remote commits is a routine situation
(as opposed to a being a huge red flag in a repository where only one or two
committers are allowed to write).

Similarly, since most commits end up being rebased, there can be no post-fact
validation to find out if there are any commits that did not go through
review -- their patch-id would likely no longer match the mailing list
submission anyway (at least, there would be too many false-positives).

This situation could be partially mitigated if commits were cryptographically
signed, but they don't appear to be.

GCC and other projects are sufficiently high targets that we should not trust
the infrastructure to be secure or admins to be above being bribed or forced
under duress.

> Anyone with commit access can create their own branches in their 
> refs/users/ namespace if they wish, and use them without needing review 
> for commits going there.  Shared development branches under 
> refs/heads/devel/ have whatever rules are established by the people 
> setting up those branches.

From the git backend perspective, this is not optimal, because the resulting
packs contain extra objects that aren't interesting to most cloners. For
example, if I only leave refs/heads and refs/tags in the gcc repository, I get
rid of over 1.1 million extra objects (from 3.9 million to 2.8 million) and
the pack shrinks from 1.8GB to 1.1GB.

To me, it makes more sense to separate this into multiple repositories and
relegate vendor/user branches to their own trees. They still share objects
behind the scenes, but packs and cloning is much more optimized.

-K