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 795073858D37 for ; Mon, 26 Sep 2022 21:53:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 795073858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x0b.wildebeest.org [172.31.17.141]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id DAE183000462; Mon, 26 Sep 2022 23:53:14 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id 5E9FB2E8158A; Mon, 26 Sep 2022 23:53:14 +0200 (CEST) Date: Mon, 26 Sep 2022 23:53:14 +0200 From: Mark Wielaard To: overseers@sourceware.org Cc: Ian Lance Taylor Subject: Re: Moving sourceware into the future Message-ID: References: <87ler4qcmo.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3033.4 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 Ian, On Mon, Sep 26, 2022 at 07:07:20AM -0700, Ian Lance Taylor via Overseers wrote: > The first is succession planning. Sourceware is essentially a community > project with a relatively small number of people keeping it going. It > needs trusted and capable people to step it to continue to maintain it. > Where are those people going to come from? We shouldn't simply hope > that it will keep carrying on as before. Yes! This is admittedly an important reason of why we are joining the Conservancy as a member project. We are at the point in the process where we will have to form a PLC (Project leadership committee). This will initially be some of the active overseers, some emiritus and representatives of the hosted projects who help out with the infrastructure. One part of their job is making sure the plc itself and the overseers get refreshed from time to time. Another part is selecting paid contractors where necessary. One of the Conservancy services is "Leadership Mentoring, Advice and Guidance" where we can ask other project leaders how to effectively deal with this. I also found that publishing these public roadmaps really helped attracting more people. People spontaniously contacted me if they could help with some setup of something we hadn't gotten to yet. Or they offered resources to make a service better. And Frank's idea of having a specific "meta" Sourceware bugzilla component also already seems to pay off with people looking at what Sourceware needs and picking up issues to work on. Not all these people will become active overseers or join the PLC, but I already feel better about attracting new talent. > The second, mentioned in Mark's e-mail, is security. I hope that we can > all agree that there are highly intelligent, highly motivated people > seeking to break security on GNU/Linux and other free operating systems. > Years ago Ken Thompson laid out the roadmap for attacking an operating > system via the compiler and other code generation tools. These days > these are known as supply chain attacks. I think that the free software > community should reasonably insist that sourceware be defended against > these kinds of attacks with mechanisms for prevention and detection and > restoration. This is a hard job. Again yes! Although the largest part of defending against "supply chain attacks" depends on project policy changes, like whether to adopt signed commits as Ulrich suggested on the gcc list recently: https://gcc.gnu.org/pipermail/gcc/2022-September/239450.html Or adopting some form of patch attestation like I had wanted to discuss in the Cauldron BoF: https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide17 (see also the slides before and some of the presenter notes by pressing 'p' if you have javascript enabled) One issue with defending against "supply chain" or having a "cybersecurity" plan is that it means different things to different people. Which makes it hard to have a good threat-model. Without which you cannot really make sure you "defended" against anything. Although I think the slsa method https://slsa.dev/ is way too involved and heavy-weight for most projects to adopt I thought they made a good analysis of the different supply chain threats and how to protect against them: https://slsa.dev/spec/v0.1/threats For us only the source integrity threats are applicable: https://slsa.dev/spec/v0.1/threats#source-integrity-threats Where roughly "(A) Submit unauthorized change" threads are project policy issues (but which the hosting platform should support). And "(B) Compromise source repo" are hosting platform issues. There are also https://slsa.dev/spec/v0.1/threats#availability-threats which can be solved with more mirroring. One nice property of us doing everything openly an publicly is that we generally don't have to defend against leaking "secrets". And if you make sure that (proposed) code changes can be verified or attested by the actual developers then if you have mirrors (easy for git, now possible for the mailinglist through our public-inbox setup) then even if one host gets compromised you will still be able to check the whole "supply chain" against a mirror or your local copy. Cheers, Mark