Moving sourceware into the future

[Mark Wielaard]

Hi Ian,

On Mon, Sep 26, 2022 at 07:07:20AM -0700, Ian Lance Taylor via Overseers wrote:
> The first is succession planning.  Sourceware is essentially a community
> project with a relatively small number of people keeping it going.  It
> needs trusted and capable people to step it to continue to maintain it.
> Where are those people going to come from?  We shouldn't simply hope
> that it will keep carrying on as before.

Yes! This is admittedly an important reason of why we are joining the
Conservancy as a member project. We are at the point in the process
where we will have to form a PLC (Project leadership committee). This
will initially be some of the active overseers, some emiritus and
representatives of the hosted projects who help out with the
infrastructure. One part of their job is making sure the plc itself
and the overseers get refreshed from time to time. Another part is
selecting paid contractors where necessary. One of the Conservancy
services is "Leadership Mentoring, Advice and Guidance" where we can
ask other project leaders how to effectively deal with this.

I also found that publishing these public roadmaps really helped
attracting more people. People spontaniously contacted me if they
could help with some setup of something we hadn't gotten to yet. Or
they offered resources to make a service better. And Frank's idea of
having a specific "meta" Sourceware bugzilla component also already
seems to pay off with people looking at what Sourceware needs and
picking up issues to work on. Not all these people will become active
overseers or join the PLC, but I already feel better about attracting
new talent.

> The second, mentioned in Mark's e-mail, is security.  I hope that we can
> all agree that there are highly intelligent, highly motivated people
> seeking to break security on GNU/Linux and other free operating systems.
> Years ago Ken Thompson laid out the roadmap for attacking an operating
> system via the compiler and other code generation tools.  These days
> these are known as supply chain attacks.  I think that the free software
> community should reasonably insist that sourceware be defended against
> these kinds of attacks with mechanisms for prevention and detection and
> restoration.  This is a hard job.

Again yes! Although the largest part of defending against "supply
chain attacks" depends on project policy changes, like whether to
adopt signed commits as Ulrich suggested on the gcc list recently:
https://gcc.gnu.org/pipermail/gcc/2022-September/239450.html
Or adopting some form of patch attestation like I had wanted to
discuss in the Cauldron BoF:
https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide17
(see also the slides before and some of the presenter notes by
pressing 'p' if you have javascript enabled)

One issue with defending against "supply chain" or having a
"cybersecurity" plan is that it means different things to different
people. Which makes it hard to have a good threat-model. Without which
you cannot really make sure you "defended" against anything.

Although I think the slsa method https://slsa.dev/ is way too involved
and heavy-weight for most projects to adopt I thought they made a good
analysis of the different supply chain threats and how to protect
against them: https://slsa.dev/spec/v0.1/threats

For us only the source integrity threats are applicable:
https://slsa.dev/spec/v0.1/threats#source-integrity-threats

Where roughly "(A) Submit unauthorized change" threads are project
policy issues (but which the hosting platform should support). And
"(B) Compromise source repo" are hosting platform issues.

There are also https://slsa.dev/spec/v0.1/threats#availability-threats
which can be solved with more mirroring.

One nice property of us doing everything openly an publicly is that we
generally don't have to defend against leaking "secrets". And if you
make sure that (proposed) code changes can be verified or attested by
the actual developers then if you have mirrors (easy for git, now
possible for the mailinglist through our public-inbox setup) then even
if one host gets compromised you will still be able to check the whole
"supply chain" against a mirror or your local copy.

Cheers,

Mark