From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 46B0D3858D37 for ; Tue, 27 Sep 2022 01:31:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 46B0D3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org Received: from linux-libre.fsfla.org ([209.51.188.54]:56612 helo=free.home) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oczS0-0004Nn-KW; Mon, 26 Sep 2022 21:31:56 -0400 Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 28R1VjSf099045 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 26 Sep 2022 22:31:45 -0300 From: Alexandre Oliva To: "Carlos O'Donell via Overseers" Cc: "Carlos O'Donell" , Mark Wielaard Subject: Re: Sourceware / GNU Toolchain at Cauldron Organization: Free thinker, not speaking for the GNU Project References: <20220918162733.GB27812@gnu.wildebeest.org> <20220918213842.GC27812@gnu.wildebeest.org> <2db869b5-5724-18c0-e356-9e5df8f7cb4d@redhat.com> Errors-To: aoliva@lxoliva.fsfla.org Date: Mon, 26 Sep 2022 22:31:45 -0300 In-Reply-To: <2db869b5-5724-18c0-e356-9e5df8f7cb4d@redhat.com> (Carlos O'Donell via Overseers's message of "Mon, 26 Sep 2022 18:04:03 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_PASS,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: On Sep 26, 2022, "Carlos O'Donell via Overseers" wrote: > - If governments want to use FOSS tools directly, do we need to comply with security > standards like a contractor would? > - Does NIST SP 800 53r5 apply to Sourceware.org? > - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf What's the theory about which if any of these various controls would apply to GNU toolchain packages, and what the "organization" would be whose goals, mission, etc should drive the choices for each applicable control? I mean, I imagine that, if any of these requirements apply to the LF, whose employees have exclusive write access to the ultimate upstream Linux repositoriess (torvalds, stable), it would have to enforce controls on this software development project it carries out, but I don't see whether or how this carries onto companies that package, test, validate, qualify and distribute, or vice-versa. Furthermore, when we bring the GNU Toolchain packages into the context, it's not at all clear that these controls clearly aimed at proprietary software development, processes and commercial arrangements would apply to individuals or groups of individuals that get together to develop software entirely in public, as in our case. Would packagers and redistributors each consider our communities as suppliers, as external systems, or each contributor as an external developer? If there are requirements for 2FA for "privileged" access (is write access to repositories privileged?) for commercial packagers and redistributors, do they carry over to the entire community? I don't even see that such a requirement is present, let alone that it extends to the community. (and I'm not even getting at the disconnect between access controls to code repositories and actually tracking code provenance and integrity, which is entirely unrelated with access controls to a shared repository, but currently accomplished by means of digital signing and secure hash-chaining of commits, including releases) It's certainly not the case in Linux the kernel, where patches are integrated by multiple parties into various community repositories and maintainers until they eventually make Torvalds' and then later stable trees. That's a fundamentally different structure from the one we've adopted, in which maintainers and contributors have write access to the master repositories. I'd appreciate a lot more details on what key features and corresponding 53r5 controls allegedly required for compliance a migration into LF infrastructure would bring, and what community organization changes, if any, these changes would require. It would be premature to as much as consider such a migration without understanding these implications, and without information about how any such requirements apply to our communities and redistributors, it all comes across as fear mongering; more so considering that nobody else seems to be taking this extreme position in which requirements must be met not only by commercial redistributors, but by every upstream project. Such extraordinary claims must be supported by equally extraordinary evidence, and I haven't seen any. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about