Review of a secure software development process for glibc.

[Carlos O'Donell]

On 5/14/25 4:50 PM, Paul Eggert wrote:
> On 2025-05-14 12:04, Carlos O'Donell wrote:
>> the number of committers we have makes me nervous.
> 
> OK, but security shouldn't unnecessarily impede glibc's primary
> goals. We should scale any new security policy up to match the
> number of committers needed for healthy glibc development, and not
> shrink the number of committers arbitrarily down to fit a new
> security policy.

At a high level, no security policy should force a scaling back
of our development, and we should design security processes that
can scale with the community.

The reason I say the number of committers makes me nervous is that
we have no good process interlocks between (a) what was posted to
the list and reviewed and (b) what was committed to the tree.

The more committers we have the more statistically likely that we
have code committed that didn't match what was reviewed.

Failures between (a) and (b) can be accidental, and often are,
in that someone says "Oh, I'll fix just one more nit" and they
commit something broken (it has happened on more than one occasion
and even to me).

If we took everyone's commit access away, and moved to a protected
master branch, with MR/PRs, and anyone could review, with the
rule being "one human reviewer is good enough to merge", then
we would have effectively decreased the commit access to 0,
retained the same development speed and access, significantly
improved security (what you reviewed is exactly what is committed),
and have the potential to start layering on extra MR/PR rules
e.g. must pass a linter, must pass etc. all without tight
coupling to the git storage side.
  
> I assume that's the intent; just trying to make it clear.

Correct, there is no intent to restrict project access to fit any
prescribed security policy, any policy should scale up to the
current community.

-- 
Cheers,
Carlos.