public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@gnu.org>
To: "Carlos O'Donell via Overseers" <overseers@sourceware.org>
Cc: "Carlos O'Donell" <carlos@redhat.com>, Mark Wielaard <mark@klomp.org>
Subject: Re: Sourceware / GNU Toolchain at Cauldron
Date: Mon, 26 Sep 2022 22:31:45 -0300	[thread overview]
Message-ID: <orczbhy54u.fsf@lxoliva.fsfla.org> (raw)
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")

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>

  reply	other threads:[~2022-09-27  1:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-16 20:57 Zoë Kooyman
2022-09-16 21:10 ` Ian Kelling
2022-09-18 16:27 ` Mark Wielaard
2022-09-18 21:38   ` Mark Wielaard
2022-09-19 21:09     ` Mark Wielaard
2022-09-26 22:04     ` Carlos O'Donell
2022-09-27  1:31       ` Alexandre Oliva [this message]
2022-09-27 11:02       ` Mark Wielaard
2022-09-28 11:14       ` Frank Ch. Eigler
2022-09-30 13:38         ` Carlos O'Donell
2022-10-02 14:55           ` Frank Ch. Eigler
2022-10-03 13:26             ` Siddhesh Poyarekar
2022-10-03 13:53               ` Frank Ch. Eigler
2022-10-03 19:16                 ` Mark Wielaard
2022-10-03 15:55               ` Christopher Faylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=orczbhy54u.fsf@lxoliva.fsfla.org \
    --to=oliva@gnu.org \
    --cc=carlos@redhat.com \
    --cc=mark@klomp.org \
    --cc=overseers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).