Re: Role of sourceware for hosted projects

["Frank Ch. Eigler" <fche@elastic.org>]

Hi, Paolo -


Thank you for your comments.  I'll address a couple of things.

> [...]
> The obvious observation from the outside is that the two "opposing sides"
> (for lack of a better word) have different priorities on what Sourceware
> needs to provide for them.  [...]

Indeed.  And the only way we can contemplate making improvements or
fixing shortcomings is by discussing them openly.  In addition, we
have been super consistent in saying that projects are welcome to
come, stay, and leave for whatever reason if they like.  This is one
reason I don't see any necessary conflict between the SFC and LF/GTI
proposals.


> The first part of the assessment in my opinion should be that most
> projects on sourceware.org are dead.  Some of them (e.g. GSL) have
> already migrated out of Sourceware in fact, but the others should be
> archived ASAP.  Archival means [...]

Most of your suggestions can be dealt with gradually, on a per-project
basis.  I believe that passive presence on the server is harmless, so
extraordinary attempts to transport & forward stuff is not necessary.
We have hardly any cgi stuff, especially in small projects, so access
control withdrawals for long-inactive users should be sufficient to
freeze things safely --- and quickly unfreeze if new activity appears.


> [...]  A prime target for this simplification, based mostly on my
> experience with QEMU, is source control and CI.  [...]  For this
> reason, source control is the main concern of the people behind the
> GTI proposal.  [...]

I have heard this as a general concern, but it's hard to match this to
a random drastic change and believe that it would or would not help.
So instead of generalities, I believe one particular threat model that
has been uttered here and there is ... "what if someone breaks into
sourceware and alters the code repositories?".  That is a reasonable
and specific concern.

Fortunately, all the active projects already / finally use git.  (gcc
was one of the last to switch).  As you know, git already has
excellent damage resiliency with every developer having full clones,
hash based content verification, etc.  Signed tags are common.  AIUI,
git is just not that vulnerable.

In addition, any git project on sourceware has the option to go
further into security territory with gpg-signed git commit/merge/push
ops.  AIUI, this practically eliminates the possibility of malicious
code-repository damage, even with a full penetration of the server.
Sourceware's git server has supported this stuff for years.  I'm a
little bit surprised that hardly any project has taken advantage.


> [...]
> The remaining common needs of large and small projects alike [...]
> While other services such as patchwork can be included [...]

Those are reasonable suggestions, OTOH for small/medium projects, the
current set of colocated services are convenient, fully open-sourcy,
community maintained.  Attack surface, yes, I suppose, but that's
balanced against a happy developing experience.


- FChE