public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Overseers mailing list <overseers@sourceware.org>,
	Carlos O'Donell <carlos@redhat.com>
Cc: "Frank Ch. Eigler" <fche@elastic.org>, Mark Wielaard <mark@klomp.org>
Subject: Re: Sourceware / GNU Toolchain at Cauldron
Date: Mon, 3 Oct 2022 09:26:57 -0400	[thread overview]
Message-ID: <95f2c79d-1dbc-4e52-0d89-d3babdae66c5@gotplt.org> (raw)
In-Reply-To: <YzmmfQipU4yvXOfA@elastic.org>

On 2022-10-02 10:55, Frank Ch. Eigler via Overseers wrote:
> 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.

The point is that targeting all of sourceware would be easy with shared 
resources; compromising a single service leaves every other service on 
the machine vulnerable.  In fact we've seen this in action multiple 
times in the past (although I doubt if they're actual exploit attempts, 
just load issues) with sourceware where one bogged down service ends up 
worsening experience for other services.

It's pretty much standard practice today to isolate services into 
separate machines and/or containers depending on their criticality.

> 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.

At least for GNU toolchain we have never really blessed other clones. 
The only blessed way to get sources is via sourceware.  Also a DoS is 
the least of our concerns.  An unauthorized access could potentially end 
up compromising the integrity of *all* data on the system, which means 
multiple projects get affected in one fell swoop.

Sid

  reply	other threads:[~2022-10-03 13:27 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
2022-10-03 13:26             ` Siddhesh Poyarekar [this message]
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=95f2c79d-1dbc-4e52-0d89-d3babdae66c5@gotplt.org \
    --to=siddhesh@gotplt.org \
    --cc=carlos@redhat.com \
    --cc=fche@elastic.org \
    --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).