Ian Jackson dijo [Wed, Jun 12, 2024 at 12:52:52PM +0100]: > 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.)
This is an important point, as you intend to give the dgit server a lot of responsability and power. After all, were Salsa (or dgit, or whatever) capable of modifying and inserting hostile bits in built packages from a clean Git tree would be catastrophic. However... > 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). Salsa is a set of services structured around, and based upon, a set of Git repositories. Git has the excellent property, as you are aware, that it's very easy to replicate repositories and be reasonably sure that all copies are perfectly equivalent. Even more so if SHA256 were to be adopted as soon as it is available, as Russ' analysis points out. I am still making my way through the discussion, however, and there are many bits I haven't understood. But the project has (mostly) decided and adopted Salsa as our project-wide Git "thingy". If it were feasible to adequate Salsa to add the ACLs needed for tag2upload to be securely deployable, I don't follow the need to have a second Git implementation we'd all have to interface with (in order to use tag2upload). And even if Salsa is deemed insufficiently prepared (or having a too large vulnerability footprint), a second, hidden Git-based server could be made to pull from Salsa, quietly syncing and acting when the right tags are found. And, of course, loudly complaining to users if any invalid operation (i.e. history rewrites involving published tags) were attempted. I am mentioning this because I see quite a bit of friction in this regard. Some people see your tag2upload proposal as a step to diminish Salsa's place in Debian and probably even have it fully replaced in the future. I'm just suggesting this as a way to keep our project Git interacions with Salsa. Again, I'm jsut in a first stage of understanding the proposal and what it involves, but... am I pointing in a generally correct direction?
