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

On Wed, 24 May 2023, Konstantin Ryabitsev wrote:

> This workflow has one important problem -- you must ultimately trust the
> integrity of your infrastructure. It would be very easy for a malicious actor

Hence the importance of limiting access to infrastructure - and limiting 
what pieces of infrastructure have access to what others (rather than the 
present arrangements where many different services run on the single 
system with the master repository and with permissions allowing to write 
to it).

> 1. they can override any server-side validations
> 2. they can disable email notifications

A commit entering the repository without appearing on the mailing list is 
itself suspect.  (It can happen, but it's very rare; maybe about once a 
year for GCC.  The only cause I know of is a bug in the commit email 
generation that makes it fall over when the diffs are not valid UTF-8.)  
In the GCC case the commit emails include sequential numbers since the 
last release branched off; the motivation of those numbers isn't to make 
missing emails easy to spot (rather, they help with Jakub's system for 
speeding up bisection by having a large number of prebuilt compilers from 
different past revisions), but they do make missing emails easy to spot as 
a side effect.

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

It's quite possible commit signatures would be a useful thing to introduce 
in future.

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

See what I said in the GCC service analysis about use of delta islands to 
make this efficient.  The configuration there is:

[pack]
        island = refs/heads/
        island = refs/tags/
        island = refs/(vendors/[^/]+)/
        island = refs/(users/[^/]+)/
        island = refs/(git-(svn-)?old)/
        island = refs/(dead)/
        island = refs/(deleted)/
        island = refs/(meta)/

(I don't think the other projects do anything this complicated with refs 
that aren't fetched by default, only GCC.)

-- 
Joseph S. Myers
[email protected]