Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 13:47, Jonas Smedegaard <jonas@jones.dk> wrote:
>
> Quoting Luca Boccassi (2024-06-12 14:40:01)
> > On Wed, 12 Jun 2024 at 12:52, Ian Jackson
> > <ijackson@chiark.greenend.org.uk> wrote:
> > >
> > > Luca Boccassi writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> > > > As far as I can tell, from what was shared in these documents, the
> > > > security feature needed is an append-only repository, with safeguards
> > > > that an individual developer cannot bypass. As far as I can tell, the
> > > > same setup can be achieved with repository ACLs, and it would have the
> > > > same vulnerability: an admin with full access to the server can bypass
> > > > such measures, in either case. Is there something else I am missing?
> > >
> > > There is also an assurance question. Salsa is running gitlab, which
> > > is an extremely complicated piece of software with very many features.
> > > Any one of those features (which are constantly changing) offers an
> > > opportunity for compromise of Salsa. Also, we don't have the
> > > resources to audit all the code comeing from gitlab upstream.
> > >
> > > The attack surface of the dgit repos server is much smaller. Its
> > > supply chain integrity is much better. So it is much less likely to
> > > be compromised. (Also, diversity of implementation is helpful.)
> >
> > Given we had a very well done and professional security review (thanks
> > Russ!), I think we should defer to that and take it into serious
> > consideration, and its conclusion seems quite clear to me in this
> > regard:
> >
> > "My security recommendation in this case is therefore to centralize
> > the risk as much as possible, moving it off of individual uploader
> > systems with unknown security profiles and onto a central system that
> > can be analyzed and iteratively improved."
> >
> > So I don't think this is a good argument. One system is better than
> > two. And we need to secure all of it anyway, as Salsa is a component
> > of the solution anyway.
>
> I read the analysis more that two systems is better than one thousand
> systems.
>
> I.e. centralizing (compared to building done on developers' systems) to a
> system that can be analyzed (which Gitlab is quite a challenge to do).
"centralize the risk as much as possible" applies to both cases, as
does the justification for it. And again, Salsa is already part of the
solution, so this argument doesn't seem very strong to me.
Having a bespoke system that nobody else uses has disadvantages too.
Yes you can minimize it and tailor it to the exact use case (as it is
today, and then you'll need to forever chase the trend of software
dev, as we have seen with Alioth). No security researcher is going to
spend any time doing audits of such a system (unless we pay them to),
but there's plenty of work done analyzing Gitlab. This concept that
everything needs to be internally auditable is very weird to me for an
open source project (I expect to see it and I do see it for internal
proprietary components in entreprises), presumably any such system
will run on a Linux kernel, but we are not asking maintainers of these
systems to personally audit the entire kernel (and libc and compiler
and and and), because they are widely used components that get enough
scrutiny externally w.r.t. the project. That's a good thing. By
reusing widely available and widely used open source components we can
share the burden of security audits, maintenance, development, etc.
Reply to: