Review of a secure software development process for glibc.

[Mark Wielaard]

Hi Andrew,

On Fri, May 09, 2025 at 03:28:39PM -0700, Andrew Pinski wrote:
> There seems to be contradictory information there.
> Service isolation for sourceware: "Partially. Via containers and VMs,
> but all on a single primary system."
> 
> But then later on under `Tasks/Service`:
> "No. Process isolation only. High-availability via non-authoritative mirrors."
> 
> Which is it?

I think it is just outdated. Sourceware runs several servers at
different hardware/network providers. Which is why
https://osuosl.org/blog/osl-future-update/ is good news. Some services
run on their own server now in separate datacenters. Some only use
"process isolation" but can be turned into their own container or VM
(we did some more work towards this again when adopting anubis, where
every service got their own anubis instance) And in Q3, when the Red
Hat community cage servers will move we'll get an extra server to
isolate even more services on separate hardware.

Although security is a layered concept, this glibc project security
policy could be much better/clearer if it just concentrated on the
glibc project secure software development process itself. We have
better/separate documents for the hosting infrastructure security
parts.

Sourceware Infrastructure Security Vision
https://sourceware.org/sourceware-security-vision.html
Sourceware Security Posture
https://sourceware.org/sourceware-wiki/sourceware_security_posture/

> Note I think this document is less about security but more about how
> "do I push CTI/LF".

Yeah, it feels like we settled that idea years ago, but Carlos just
keeps trying to push for moving the glibc project to the linux
foundation every 6 months or so anyway. I wish that energy was spend
on helping out the Sourceware PLC provide the best Free Software
hosting project for core toolchain and developer tools.

> If we want to talk about security of glibc sources, we need to step
> back and think about the model of submitting patches and approvals.
> That is talk about forges and how git write access should look like.
> Right now signing up to become a glibc maintainer is just sending out
> an email and get approves. Once someone gets approval for write access
> they could push anything. That does require a lot of trust yes but
> that is what security is all about. So going to forge style, the trust
> chain is more explicit of who approved things, etc. Rather the current
> model of adding Reviewed by manually.

If you look at the Sourceware secure development practices check-list
https://sourceware.org/cyber-security-faq.html#policy-checklist
a lot of policies are about adding process steps that improve the
integrity of the code. So that it can be verified how and why changes
were done and who were involved.

Every system can be gamed, so in general we should trust but
verify. In general it isn't good if we constrain/deny people making
any changes without strict formal/technical approvals. But it should
be easy to detect if unwanted changes were made, either by accident or
by malice.

Cheers,

Mark