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

[Carlos O'Donell]

As part of our ongoing efforts to improve security and auditability of artifacts
I'd like to make concrete progress towards one of the goals in the SSDLC.

Store all forms of code based on principle of least privilege (PS.1.1, page 9)
https://sourceware.org/glibc/wiki/SSDLC/Policy/glibc#Store_all_forms_of_code_based_on_principle_of_least_privilege_.28PS.1.1.2C_page_9.29

Today we don't have an easy way to audit and review which keys have access to the repo
other than to ask a Sourceware overseer to do an audit. That has costs for overseers.
Exactly how the access changed over time is also not visible nor recorded.

The goal is to make it possible for certain project accounts to query who has access,
which keys have access, and have a record of how that changed over time.

This allows a set of maintainers/developers to easily do the following themselves:

  * Run independent checks to look for known compromised keys that have access.
  * Run scripts as part of the release process that implement the access policy
    e.g. write access removal after inactivity.

The second part is the interesting piece that is tied to the release process and
intended to limit damage done by compromised keys. It could be a process that is
triggered via a bugzilla request to Sourceware overseers, but it is an easier less
error prone process if is self-service, scriptable, and auditable via the gitolite
admin repo.

The proposal is to move from the existing git server to gitolite.

This is not a proposal to move from Sourceware, but to ask Sourceware overseers to
migrate glibc from git to gitolite.

-- 
Cheers,
Carlos.