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.)
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.
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.
Given how much resistance there is to even t2u's current dssign, I
don't think placing this much reliance on Salsa etc. is politically
viable even if it were wise (which I think it wouldn't be).
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
