Review of a secure software development process for glibc.

[Carlos O'Donell]

On 5/9/25 6:28 PM, 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?

The tables are a summary.

The table in PO.1.1 covers everything that the infrastructure provider might
consider offering, and I've updated the text to list the known primary
mechanism of isolation.

In the case of Sourceware the primary mechanism has been chroot or containers
(like php-fpm with chroot, and systemd slices with cgroups/namespaces).

The table in PO.5.1 is narrowly defined for the core services in question.

Does that answer your question?

I've updated the text to try to reflect that.
  
> Note I think this document is less about security but more about how
> "do I push CTI/LF".

The goal I want, and continue to work towards, is to improved upstream security.

If we can find incremental improvements today then I'd be happy for that.

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

This is one of the things we need to consider.

There are several steps we could take here.

Do you have any opinions on possible solutions that the community
could adopt?

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

Yes, and the number of committers we have makes me nervous.

A forge works only so long as you trust the forge.

Likewise the forge is a single point of failure.

The forge also doesn't meet our current requirements (see analysis
by Joseph Myers, and also downstream Fedora analysis in using Forgejo).
It would need more development to meet our needs, or we would have to
accept the forge as-is and work to improve it.

Distinct git, email, bugzilla, and patchwork services are potentially
more robust and resilient and meet the current community workflow
requirements.

The trust chain could be made more explicit by using gitsign [1][2]?

The idea here is you do keyless signing of all your commits.

We switch to signing with an identity and witness it in the transparency log.

-- 
Cheers,
Carlos.

[1] https://github.com/sigstore/gitsign
[2] https://docs.sigstore.dev/about/overview/