From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pine.sfconservancy.org (pine.sfconservancy.org [IPv6:2001:4801:7822:103:be76:4eff:fe10:7c55]) by sourceware.org (Postfix) with ESMTPS id 87710385627B for ; Tue, 27 Sep 2022 17:12:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 87710385627B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sfconservancy.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sfconservancy.org Received: from wn (c-71-193-148-228.hsd1.or.comcast.net [71.193.148.228]) (Authenticated sender: pono) by pine.sfconservancy.org (Postfix) with ESMTPSA id 43CCEE80D; Tue, 27 Sep 2022 17:12:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sfconservancy.org; s=pine; t=1664298742; bh=M1dSbD/OixESRjvzWIaSuDcRpPASE7BULtyMBTqKtE8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ADxwM8KQATM1lXVgr5FHug87OkbkV1DoEBh3TsdGGcwKMPP2IIb24JDE07lXa5JoC NvZfwOuQ08qTkgcQTd3GPm1bWuj0Lv3wzJw+2QFmMvyPhdPiqr//83wp8XqPRXw1Xs UAL56u54GMTWDoctELzm4CjGGuf8jZ5p7dP+KtI3kDO2eVdOQaiC0ISiUPVUzHN6PH PYl4rc3Ma8OFCpvc3exoVn1P2PDYGE2cllGvgDg8q2C3l+Gx7URYqUZYTIQpj3nyCl iQx1ANZvx3a/OTDw0wtqwyhPT6aLlKFYuVEcE5mQcXznVRS8WeXRyvx7/lM03RdARc cRJbvobtPHj0Q== Date: Tue, 27 Sep 2022 10:12:20 -0700 From: Daniel Pono Takamori To: Overseers mailing list Cc: Mark Wielaard 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=-0.1 required=5.0 tests=BAYES_20,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Thanks for the thoughtful comments on project structure and future planning. I've added some thoughts inline below. On Mon, Sep 26, 2022 at 11:53:14PM +0200, Mark Wielaard via Overseers wrote: > 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. Helping create and maintain is a really important part of the relationship between SFC and our member projects. Like everyone pointed out the "bus factor" is an important consideration for governance. Making sure that there is a robust group of people with varying backgrounds and skills makes project healthiers. Also as pointed out, working with contractors is another part of our bread and butter. Managing funds, both in fundraising and spending, is one of the core features of having a fiscal sponsor and something we take very seriously. As noted previously, finding some contractors to work on security related issues sounds like a high priority task, so we can help allocate those funds and work with you to find the appropriate people to get the work done. > 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. I've seen a lot of talk about "open governance" recently, and I think technical and governance roadmaps are a great place to start! Once a governance team/ plan has been created, outside people are much more likely to want to participate since they'll know the rough structure of the project. It's so hopeful to hear that there are people interested in volunteering and helping the project out! > > 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. I won't speak to any of the technical or infrastructural points about security, but to say that we leave those choices up to our projects and support them however they see fit. Also hopefully there are some free software options in the burgeoning "software supply chain" and artifact verification spaces, as it's becoming increasingly clear that there are some open questions in those areas. Let me know if you have any questions, -Pono on behalf of Software Freedom Conservancy > > Cheers, > > Mark