Updated Sourceware infrastructure plans

[Mark Wielaard <mark@klomp.org>]

Hi Hackers,

Thanks for all the mailinglist feedback and discussion during the Open
Office hour on the Sourceware 2024 Plan and Security/Mitigation ideas.
It really helps the Sourceware Project Leadership Committee refine the
infrastructure plans with the help of the Software Freedom Conservancy.

We started on the "aging inactive users" process by sending emails to
the first batch of users without any activity in the last year.
https://inbox.sourceware.org/overseers/ZhQZXogZMozVjIYn@elastic.org/T/

Various people already replied saying it was OK to disable their
account. But we also noticed that some of the account contact
information is no longer valid. Please keep your account details up to
date so that we always have a way of contacting you.

Please see the account management page on how to set your current
email address: https://sourceware.org/sourceware/accountinfo.html

We are also looking at refreshing our pdw new account process
https://sourceware.org/bugzilla/show_bug.cgi?id=30218 We don't want to
make things too difficult, but will follow processes strictly.
Comments welcome.

Also the release upload process might get revamped.
https://sourceware.org/bugzilla/show_bug.cgi?id=29643 The current
candidate is the the GNU upload script since that is familiar to the
various GNU toolchain projects already hosted on Sourceware. And it
has the advantage that it makes sure all releases are signed with
known PGP keys. But other ways which make similar guarantees could be
used too.

We also encourage projects to use signed git commits where it makes
sense. This can be done through the gitsigur process which supports
hoos to only allow known (registered) signatures.
https://inbox.sourceware.org/overseers/ZIz4NB%2FAqWpSNj5d@elastic.org/
But can of course also be done in other ways. See this overview of how
sigsigur, sigstore and b4 can provide a signed commit/release workflow:
https://inbox.sourceware.org/overseers/ZJ3Tihvu6GbOb8%2FR@elastic.org/

Given this focus on (signing) keys we are also looking for ways to
provide at least the admins and release managers with hardware keys.

Another thing we started was isolating more processes. For that we
will have to adjust some things that might impact current services
(sorry). The cygwin calm process that manages package uploads is now
its own systemd service. And we will have to adjust some git
hooks. Specifically for those projects that use the adacore hooks we
would like to adjust how they sent emails:
https://inbox.sourceware.org/gcc/20240416105622.GD1423@redhat.com/T/

In general we would like the git hooks to do as little as possible
directly. Just do the mandatory checks. For longer running things we
have the buildbots or dedicated services.

One such dedicated isolated service https://snapshots.sourceware.org/
provides projects like glibc, valgrind, libabigail and elfutils with
automated source and documentation snapshots from current git. This is
really helpful to make sure release scripts work and has caught issues
early so they don't suddenly pop up during release time. If you
currently do have (or want to have) snapshot builds, please consider
moving them to snapshots (which integrates with builder.sourceware.org)
https://inbox.sourceware.org/gdb/20240415182815.GA1423@redhat.com/T/

Understandably there was a lot of discussion how to make sure what
goes into these snapshots/releases is really the code that was
contributed and reviewed. In a way we make it more difficult for
ourselves by having a culture of saying "This is OK, if you just
change X". And then trusting people to just commit what that "small
change". We should encourage people to always post the final patch
that they will commit. Then we can create tools that automatically
check that everything committed was as posted (and approved).

We also should make sure that all generated files (either in git or in
the release/snapshot tar balls) can be reliably and reproducibly
regenerated. This also helps the (pre-commit) CI buildbots. We already
have the autoregen bots for gcc and binutils-gdb. And Christoph has
been working on extending the scripts to regenerate more kinds of
files.
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
https://builder.sourceware.org/buildbot/#/builders/binutils-gdb-autoregen
https://inbox.sourceware.org/20240417145033.2077525-1-christophe.lyon@linaro.org/

Some of the above issues are made a little more tricky because of the
email-workflow we are using. But people seem really attached to it.
But we also saw that new contributors struggle with getting an initial
(email) setup.

So we would like to prototype a "pull-request" style infrastructure.
Maybe via installing extra bits like sourcehut, or just a lower
privilege gitorious instance, to give non-committers a place to plop
their code.

But we like to get more feedback on what people really think a
"pull-request" style framework should look like. We used to have a
gerrit setup which wasn't really popular. And we already have a
sourcehut mirror that can be used to turn your "pull-requests" into a
git send-email style submission (without having to setup any
email/smtp yourself): https://sr.ht/~sourceware/

This overview is already pretty long. And this only lists some of the
plans for which we got feedback. There are more topics/plans listed in
the original Sourceware 2024 Plan and the Sourceware mitigating and
preventing the next xz-backdoor thread:

https://inbox.sourceware.org/20240325095827.GI5673@gnu.wildebeest.org/
https://inbox.sourceware.org/20240401150617.GF19478@gnu.wildebeest.org/

More feedback is always welcome. See the various contact options at
https://sourceware.org/mission.html#organization

Thanks,

Mark