On Wed, 12 Jun 2024 at 12:52, Ian Jackson
<ijack...@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.
> And, while I find gitlab and Salsa very convenient, we have already
> had one git forge fall by the wayside. As I say, the dgit repos
> server has already survived the death of one forge and it needs to
> survive any problem with Salsa.
The proposed solution already integrates with Salsa, so this point
seems moot to me. If we ever move off Gitlab, this would move too.
> Finally, using Salsa instead would involve modelling the Debian upload
> permissions model in repository ACLs, which we don't currently do.
> We would need to link uploaders' PGP keys to their ssh keys and rely
> on ssh keys, I think.
Why is that needed? From reading the document here:
https://salsa.debian.org/dgit-team/dgit/-/blob/master/TAG2UPLOAD-DESIGN.txt#L14
it seems to me developers would not be allowed at all to push directly
to this namespace, but only the tag2upload service would be allowed
(developers push to their normal repo, as they do today) by the ACLs,
and deleting tags/force pushing/deleting branches/etc would be
disallowed on top of that.
