[CTI] glibc SDDLC: Review git to gitolite transition and access policy - Volunteer to write a script?

Carlos O'Donell carlos@redhat.com
Tue Dec 2 16:23:50 GMT 2025


In August we started a conversation around glibc switching to gitolite:
https://inbox.sourceware.org/libc-alpha/4e9f65ea-a1bf-4d69-9dd5-63aa301f0b42@redhat.com/

With my CTI TAC hat on I reviewed the infrastructure requirements again, and
started progressing on some of the technical details to move from git to
gitolite and if the glibc SSDLC policy could be implemented.

Summary
=======

Completed first part of a proof of concept that the gitolite configuration
can achieve the same functional effect for glibc as git e.g. push
restrictions, access restrictions etc., but with improved observability
and finer grained access controls.

Reviewed the glibc SSDLC policy as written and tested with gitolite,
noting that 94 keys would be considered inactive and removed.

Created the list of "next steps" to review including web hooks for the
entire pipeline.

Details
=======

Goals:

  * Provide git-based audit around who has write access to the repo.
  * Allow easy git-based add/remove of keys for repo access to implement policy.

Status update:

  * Setup gitolite3 locally to experiment with each step of the conversion.
    * Configured gitolite to deny force push on master and release.
    * Configured gitolite to allow force push on other branches.
    * Configured gitolite to allow only fast-forward-merges on master and release.
    * Configured gitolite to allow merge commits on other branches.
    * Configured gitolite to support finer branch ownership rules.
  * Reviewed requirements for hooks and secured implementation.
  * Looking at keys we allow access to and which would go into gitolite repo.
  * Audit committers to the repo in the past 2 releases
    * Total of 39 committers.
  * Audit glibc group membership.
    * Total of 133 committers

Following the glibc SSDLC process we would remove 94 active keys
for glibc write access.

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
"Code write access should be revoked if writes have not occurred within the last 12 months."

Last 12 months could be treated loosely as last 2 releases, but the policy
could be clarified.

The following people would keep their access (from public git commit list):

Aaron Merey <amerey@redhat.com>
Adhemerval Zanella <adhemerval.zanella@linaro.org>
Andreas K. Hüttel <dilfridge@gentoo.org>
Andreas Schwab <schwab@suse.de>
Andrew Pinski <quic_apinski@quicinc.com>
Arjun Shankar <arjun@redhat.com>
Aurelien Jarno <aurelien@aurel32.net>
caiyinyu <caiyinyu@loongson.cn>
Carlos O'Donell <carlos@redhat.com>
Collin Funk <collin.funk1@gmail.com>
DJ Delorie <dj@redhat.com>
Florian Weimer <fweimer@redhat.com>
Frédéric Bérat <fberat@redhat.com>
H.J. Lu <hjl.tools@gmail.com>
Jakub Jelinek <jakub@redhat.com>
John David Anglin <danglin@gcc.gnu.org>
Jonathan Wakely <jwakely@redhat.com>
Joseph Myers <josmyers@redhat.com>
Maciej W. Rozycki <macro@redhat.com>
Mark Wielaard <mark@klomp.org>
Michael Jeanson <mjeanson@efficios.com>
Mike FABIAN <mfabian@redhat.com>
Noah Goldstein <goldstein.w.n@gmail.com>
Paul Eggert <eggert@cs.ucla.edu>
Paul Pluzhnikov <ppluzhnikov@google.com>
Paul Zimmermann <Paul.Zimmermann@inria.fr>
Pavel Kozlov <pavel.kozlov@synopsys.com>
Peter Bergner <bergner@tenstorrent.com>
Sachin Monga <smonga@linux.ibm.com>
Sam James <sam@gentoo.org>
Samuel Thibault <samuel.thibault@ens-lyon.org>
Siddhesh Poyarekar <siddhesh@sourceware.org>
Stafford Horne <shorne@gmail.com>
Stefan Liebler <stli@linux.ibm.com>
Sunil K Pandey <sunil.k.pandey@intel.com>
Tulio Magno Quites Machado Filho <tuliom@redhat.com>
Uros Bizjak <ubizjak@gmail.com>
Wilco Dijkstra <wilco.dijkstra@arm.com>
Yury Khrustalev <yury.khrustalev@arm.com>

Todo:

  * Automate removal of keys that haven't committed in 2 releases.
  * Verify UTF-8 allowed in commit messages.
  * Review nginx, gunicorn and flask to serve webhook results.
  * Webhook email notification configuration and testing.
    * Must allow 5MiB max diff?
    * Must send at most 500 commit emails?
    * Customize commit URL.
  * Webhook for minimal style checker?
    * Reject mailing list in the source address - Easy.
    * Style check content - Move to pre-commit CI?
  * Webhook for bugzilla update?
  * Webhook for IRC update?
     
Would anyone like to volunteer to write a script to do the 1 year
look back with support for using tags? And alias lists to filter
out the same people with different emails? And retain a mapping of
the canonical email to the current key file in the gitolite repo?

Should we create a glibc->admin bug in bugzilla to track the work?

-- 
Cheers,
Carlos.



More information about the Libc-alpha mailing list