public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@elastic.org>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Overseers mailing list <overseers@sourceware.org>,
	Mark Wielaard <mark@klomp.org>
Subject: Re: Sourceware / GNU Toolchain at Cauldron
Date: Sun, 2 Oct 2022 10:55:57 -0400	[thread overview]
Message-ID: <YzmmfQipU4yvXOfA@elastic.org> (raw)
In-Reply-To: <940b60c6-54fe-d4d2-22d1-d93dcf2aaf79@redhat.com>

Hi -

> >> - Defense in depth
> >>   - Multiple servers, each with distinct services.
> >>   - Multiple servers for one service where possible.
> > 
> > Depends on the threat model.  Which one are you concerned about?

> Consider an attacker simply looking to disrupt services (DoS, DDos)
> using another service on the current system. The more services
> present on the system the more the opportunity to do this kind of
> attack.

I don't quite see the "more opportunity".  If someone wants to take
out a particular source hosting site, they'll go after it, whether or
not the target site is sharing resources with others.

We are fortunate to use fully decentralized source control systems,
where full clones at developers - and at other services like github
etc. - are routine, and permit work to continue.  I'd be surprised to
hear of any organization hoping to hurt free software development by
DoS'ing the sites - it'd be a futile gesture.


> >> - 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?
> >>     [...]

> > If we don't have evidence that it does, what is the purpose of
> > bringing it up?

> Two downstream users of our sources have cited NIST SP 800-53 as
> something they had to comply with

Downstream corporations distributing products based on FOSS are
irrelevant to this question.


> and I want to dig more into two possible scenarios:
>
> (a) Is there an expectation that upstream source control
> repositories need to meet this regulation as well as the
> downstreams?  (b) If we met the regulation would it improve FOSS
> adoption and support downstream users?

I can only assume that you already have evidence/argument in the
affirmative for these questions, otherwise why are we discussing any
of this?  Can we hear that evidence/argument please?


> >> It is two proposals.
> >>
> >> A fiscal sponsor for infrastructure in the OpenSSF via the GNU
> >> Toolchain Infrastructure project at the Linux Foundation.
> >>
> >> A proposal to use managed services with the Linux Foundation IT for
> >> projects currently at sourceware.org.
> > 
> > Are they separable?
>
> They are, the fund is designed to support more than just managed services.

That's not quite the same thing.  Are the funds available for novel
things that the various development communities may start requesting,
**instead of** redirecting the vast majority to LF-IT for managed
services?  Or, are managed services an inseparable component of this
proposal?


- FChE

  reply	other threads:[~2022-10-02 14:55 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
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 [this message]
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=YzmmfQipU4yvXOfA@elastic.org \
    --to=fche@elastic.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).