Sourceware / GNU Toolchain at Cauldron

[Alexandre Oliva]

On Sep 26, 2022, "Carlos O'Donell via Overseers" <overseers@sourceware.org> 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 <https://stallmansupport.org>