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 187653858D39; Tue, 2 Apr 2024 23:20:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 187653858D39 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 187653858D39 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=1712100019; cv=none; b=I3VknTpBCnDwjxa3hxxlO2zZgTgkVLUAjO41JZAIe+7sKZ5OBXlVR02qhNLEw4wQI5FarwrKsDT21C9CK7cvhL4lWov4SrhSTO2UupLjSGPxc5JaKmLNJYppCLDtw87ZJOsgOXnLQLpkd31NQzN6R6+dsgCH0J2CpCaAz3k6rrk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712100019; c=relaxed/simple; bh=nzeYSgnOZdIW94yUVW4XPyOPh40SoPb0uE9M6dFIW70=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=lejCMsk/B3/Ey/SiOM5ZIfkSCHSTCXG/wLdqXb/kpsRq/4zKadd7BtlDahUX3jDQHtc16hfFt0YpW0DFhT+o/ZjZyvj/AWL/4AMty8gDKhLgY2/E+ISnae9k+zW3xcIDl2tVWlsUOyFbwzCH+guHMyEDJ2RX+gdGVelepHIbqWA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 1D6283000674; Wed, 3 Apr 2024 01:20:16 +0200 (CEST) Date: Wed, 3 Apr 2024 01:20:16 +0200 From: Mark Wielaard To: Guinevere Larsen Cc: Sandra Loosemore , overseers@sourceware.org, gcc@gcc.gnu.org, binutils@sourceware.org, gdb@sourceware.org, libc-alpha@sourceware.org Subject: Re: Sourceware mitigating and preventing the next xz-backdoor Message-ID: <20240402232016.GG9065@gnu.wildebeest.org> References: <20240329203909.GS9427@gnu.wildebeest.org> <20240401150617.GF19478@gnu.wildebeest.org> <077b9dd5-0df1-4384-a9d1-58e4283caf09@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <077b9dd5-0df1-4384-a9d1-58e4283caf09@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,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, On Tue, Apr 02, 2024 at 07:08:59PM -0300, Guinevere Larsen wrote: > On 4/2/24 16:54, Sandra Loosemore wrote: > >On 4/1/24 09:06, Mark Wielaard wrote: > >> > >>We should discuss what we have been doing and should do more to > >>mitigate and prevent the next xz-backdoor. There are a couple of > >>Sourceware services that can help with that. > >> > >>TLDR; > >>- Replicatable isolated container/VMs are nice, we want more. > >>- autoregen buildbots, it should be transparent (and automated) how to > >>   regenerate build/source files. > >>- Automate (snapshot) releases tarballs. > >>- Reproducible releases (from git). > >> > >>[snip] > > > >While I appreciate the effort to harden the Sourceware > >infrastructure against malicious attacks and want to join in on > >thanking everyone who helped analyze this issue, to me it seems > >like the much bigger problem is that XZ had a maintainer who > >appears to have acted in bad faith.  Are the development processes > >used by the GNU toolchain components robust enough to cope with > >deliberate sabotage of the code base?  Do we have enough eyes > >available to ensure that every commit, even those by designated > >maintainers, is vetted by someone else?  Do we to harden our > >process, too, to require all patches to be signed off by someone > >else before committing? > > [...] > > Beyond that, we (GDB) are already experimenting with approved-by, > and I think glibc was doing the same. That guarantees at least a > second set of eyes that analyzed and agreed with the patch, I don't > think signed-off would add more than that tag (even if security was > not the reason why we implemented them). Yes, I agree having a policy of requiring all patches to be reviewed and showing that by adding tags like Approved-By is a good thing. And I think the gdb approach is simple and sane: https://sourceware.org/gdb/wiki/ContributionChecklist#Receiving_positive_reviews Like all the other suggestions it wouldn't really prevent all attacks. But you shouldn't do this just for "security" anyway. I would even say that if you do something only to get a security "badge" then you are doing it wrong. The "hardening" projects above were also not just for "security" but also because they are good and sane things to do anyway. We try to put everything in separate containters or isolated VMs also because that just makes maintenance easier, helps migrating workloads, shows users how setup the services locally. Having automated reproducible snapshots and releases also helps having clear procedures for regenerating files, makes (pre-commit) CI more reliable, helps bootstrappability. The reason I only listed the above four "hardening" steps was because they have clear Sourceware infrastructure services that could help and that we are working on already anyway. Having a Reviewed-By policy is really "just" a project policy that doesn't require any infrastructure help. Although we could have a git push hook that makes it mandatory. You could however go further and use signed commits or pushes, Both of which Sourceware infrastructue supports: https://inbox.sourceware.org/ZJ3Tihvu6GbOb8%2FR@elastic.org/ Or if the project wants to we could migrate them to gitolite and/or install strict hooks for who may push to (release) branches. Just let us know. The Sourceware Infrastructure is ready, but most of these issues are really project policy. Cheers, Mark