glibc SSDLC: Proposal to use gitolite for access to source code.

[Carlos O'Donell]

On 8/19/25 9:58 AM, Joseph Myers wrote:
> On Tue, 19 Aug 2025, Carlos O'Donell wrote:
> 
>> The proposal is to move from the existing git server to gitolite.
> 
> Note that this will need an analysis / design for the things currently
> done via hooks (both configuration that rejects some pushes that do not
> follow policy, and actions such as sending commit emails after a push is
> accepted).  Based on the analysis of the things done by hooks, we need to
> figure out for each one: should it be implemented in some other (hopefully
> more secure) way given a repository run with gitolite (in particular,
> *not* running hook code in the context of gitolite itself), or should it
> be dropped?
  
I agree.

I want to expand this briefly.

(a) gitolite servers reserve "update" for their own uses.

(b) gitolite servers have a concept called VREF (virtual references) that
     provide constraints to the push (additional DENY rules).

The simplest way to make the existing hooks work is to add them as
a VREF directly. So we could attempt a direct port to gitolite without much
additional analysis.

The VREF's however are run directly from the gitolite perl code via open
and as such run directly as the gitolite user, though this would be more
isolated, it's still a large amount of code.

I agree a better next-step is a conversion that does checks in gitolite
core where such checks exist.

I've started an analysis here:
https://sourceware.org/glibc/wiki/SSDLC/Projects/gitolite

I think a next step might be to setup a gitolite repo to prototype all
the required pieces.

-- 
Cheers,
Carlos.