Gunnar Wolf <gw...@debian.org> writes: > 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 know that you already self-replied to this saying basically the same thing, but for anyone reading the thread, I wanted to make clear that the suggestion in your second paragraph is indeed how the dgit-repos server works. No one has to interact with the dgit-repos server directly. The signed tag is pushed only to Salsa, and the push to the dgit-repos server is done under the hood by the tag2upload server. The dgit-repos server offers some other features unrelated to tag2upload that people may wish to use (such as dgit clone), but for tag2upload purposes it can be ignored entirely for the normal workflow. It's there to keep a persistent append-only record of the exact Git trees that were converted to source packages, should that be needed for later detection or tracing of some issue. There was more confusion about this point than I had anticipated, so I want to emphasize that the dgit-repos server is not a forge, is not a competitor to Salsa, doesn't replace Salsa in any way, and is not something that people interact with the way that they interact with Salsa. It's much closer to a Git equivalent of archive.debian.org: a persistent historical record accessible via the Git protocol and (as I discovered during this thread) a cgit web interface. I think it's important to keep the dgit-repos server separate from Salsa for the reasonsn that Ian pointed out in another part of the thread, most of which reduce to the fact that Salsa is, necessarily, a very large and complicated thing with a ton of functionality because it is trying to solve a very hard problem, namely interactive development using a huge variety of Git-based workflows. Keeping the persistent append-only archive separate maintains separation of duties, provides a nice security boundary, similar in spirit to keeping off-site backups, and reduces the lateral movement security threat by making it harder to leverage a Salsa compromise into a compromise of the historic record of our Git trees. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
