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

On 2023-05-24 12:29, Konstantin Ryabitsev wrote:
> 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.

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 
gatekeeper committer could also fabricate commits and push to the 
central repository in the same way.  In fact, the gatekeeper committer 
could choose to do worse, like delaying (or declining to merge) someones 
patches.

Signed commits would be nice, but we're not there yet as a community.

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

That would be a nice optimization.  In fact, an interesting workflow 
hack here could be to have separate per-maintainer repositories that a 
central repository pulls from, subject to some checks passing.  It won't 
solve any of the trust problems since the repositories will all be in 
the same infrastructure, but it will add more validation in the 
pipeline, while reducing the main repository size.

Thanks,
Sid