From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 3D9BF3858D20; Wed, 17 Apr 2024 23:27:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3D9BF3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3D9BF3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=45.83.234.184 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713396448; cv=none; b=fIXve01R6A6jj4bmQwvupqQwqSmZx2NuS2sF+9w+jJgj/pbk0+BdQL4V9acflmgqvFQWTVlQOeP0izOlf/Q5neHbTW2Kt0HQoCjlhM8oqORZwX1g9GOZeEfp7HOGMr5wLBV4KzAnDZT/qICeYWYAirAjRCcy3nTZ95EUDRJSZmg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713396448; c=relaxed/simple; bh=Wdx1PIOURGtHU1bBifuWlDJcPFmnUWSyDD69upH1qeo=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=xYnSeCk3KNMDhoXMo4BUPkqFyRCFU6MfdiMHMNSQMgn8UaInma/tEE7oegsxbgrEspkMfeh0L/+IpXonWRBo88DzcMGBd05zuoBwxVL0bK/Xvr/pGxlDcfW9s3BhRA86C5BKnAcv7dDu11i+WLFPZDvocqCNQKmYrunNtx751SE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 29D843000587; Thu, 18 Apr 2024 01:27:25 +0200 (CEST) Date: Thu, 18 Apr 2024 01:27:25 +0200 From: Mark Wielaard To: overseers@sourceware.org Cc: gcc@gcc.gnu.org, binutils@sourceware.org, gdb@sourceware.org, libc-alpha@sourceware.org Subject: Updated Sourceware infrastructure plans Message-ID: <20240417232725.GC25080@gnu.wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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