Re: Moving sourceware into the future

[Daniel Pono Takamori <pono@sfconservancy.org>]

Thanks for the thoughtful comments on project structure and future planning.
I've added some thoughts inline below.

On Mon, Sep 26, 2022 at 11:53:14PM +0200, Mark Wielaard via Overseers wrote:
> 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.

Helping create and maintain is a really important part of the relationship
between SFC and our member projects. Like everyone pointed out the
"bus factor" is an important consideration for governance. Making sure
that there is a robust group of people with varying backgrounds and
skills makes project healthiers.

Also as pointed out, working with contractors is another part of our
bread and butter. Managing funds, both in fundraising and spending,
is one of the core features of having a fiscal sponsor and something
we take very seriously. As noted previously, finding some contractors
to work on security related issues sounds like a high priority task, so
we can help allocate those funds and work with you to find the
appropriate people to get the work done.

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


I've seen a lot of talk about "open governance" recently, and I think
technical and governance roadmaps are a great place to start!
Once a governance team/ plan has been created, outside people
are much more likely to want to participate since they'll know the
rough structure of the project. It's so hopeful to hear that there are
people interested in volunteering and helping the project out!

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

I won't speak to any of the technical or infrastructural points about
security, but to say that we leave those choices up to our projects and
support them however they see fit. Also hopefully there are some free
software options in the burgeoning "software supply chain" and artifact
verification spaces, as it's becoming increasingly clear that there are
some open questions in those areas.

Let me know if you have any questions,
-Pono on behalf of Software Freedom Conservancy

> 
> Cheers,
> 
> Mark