Review of a secure software development process for glibc.

[Mark Wielaard]

Hi,

On Tue, May 13, 2025 at 05:01:25PM +0000, Joseph Myers wrote:
> On Tue, 13 May 2025, Mark Wielaard wrote:
> 
> > Totally agreed all security layers should be as transparent as
> > possible. We do try to go through bugzilla for changes. And as said
> > above all configs are in git. We should definitely look into making
> > more of that public like we already do for newer services.
> > 
> > Sorry if it feels you have to be on IRC to participate, we do have
> > other channels of communication:
> > https://sourceware.org/mission.html#organization
> 
> The point is there should be some log that shows *every* administrative 
> action and configuration change, large or small, so that people in all the 
> hosted projects can monitor it.  Then, if I want to see all administrative 
> actions done in April 2025, say, I can go and read that part of the log.
> 
> A lot of such actions will be routine, of course, but should still be 
> properly visible.  Some actions may involve security questions - it's 
> particularly important to examine the setup of any new service and the 
> security record of the software involved, for example.  And some actions 
> engage policy issues.

We already discussed on IRC (yes, I know irony, so lets summarize on
the list) and I think everybody agrees this is the ideal setup. And
this is already the case for the buildbot and forge setups. We do have
all other configs in git already. The trick will be to make sure that
those git repos don't contain any private data (keys, seeds or
passwords) before making them fully public.

>  For example, all the recent Anubis work is the sort 
> of thing where frequent (at least daily, when there are any changes) 
> reporting to the community of any changes done is important, because the 
> trade-offs involved in obstructing access to various services are the sort 
> of thing for which the hosted projects need oversight - though you may 
> need to act first to keep things running, then report details to the 
> projects so they can decide if a different trade-off is preferred.

The reason there weren't more frequent reports of changes done is
because there just weren't many config changes at all. Xe has been
consulting us (yes, on IRC) on the setup and incorporated anything
special in the default Anubis setup and docs. Once that was done it
was just a matter of adding the services as already announced on the
list. In fact the only config change done in the last 14 days was
today to enable the patchwork Thunderbird Seams plugin:
https://fosstodon.org/@sourceware/114513681248590866

> (Much 
> the same comment would apply to the past changes to restrict Bugzilla 
> account creation, as another example, since it should ultimately be for 
> the projects to decide the trade-offs between spam and losing genuine bug 
> reports, not the administrators.)

This refers to a couple of years ago when both the sourceware and gcc
bugzilla instances were changed at the same time so new user accounts
had to be manually approved. It would have been nice if there was more
discussion before that was done. But in the end it was the right
decision for both instances because the spam was just becoming
unmanageable otherwise.

I am mainly mentioning this because the original description might
make it seem like there was some deep conflict between bugzilla admins
vs project admins. But in general there are very good relationships
between the Sourceware PLC, overseers, projects admins and hosted
project developers. Please make sure to be nice to each other and
highlight when someone take responsibility to make things better. We
are all working hard to make development go as smoothly as possible.

Cheers,

Mark