On Wed, 12 Jun 2024 at 09:35, Jonas Smedegaard <jo...@jones.dk> wrote: > > Quoting Luca Boccassi (2024-06-12 10:21:40) > > On Wed, 12 Jun 2024 at 02:31, Russ Allbery <r...@debian.org> wrote: > > > > > > Luca Boccassi <bl...@debian.org> writes: > > > > > > > And on the implementation details, I really do not like the idea of > > > > having a competing git forge with Salsa. This dgit server seems to just > > > > be a ye olde git-web interface. > > > > > > Does it support gitweb? I thought it only supported regular Git > > > operations, but I could be mistaken. > > > > I might be wrong, but this is what this looks like to me (it was > > linked to me on IRC yesterday, wasn't aware of it before): > > > > https://browse.dgit.debian.org/ > > > > > > If this goes forward, in my opinion it should exclusively use Salsa > > > > as the git server, to avoid duplicating infrastructure. > > > > > > I think you want the Git archive to be entirely separate from Salsa > > > so that it's a reliable source of tracing information. You don't > > > want to support force pushes, for example; the whole point is that it > > > should be append-only, which would be a controversial choice for > > > Salsa but which is fine for the archives of the uploaded packages. I > > > would also want a much smaller attack surface for that type of record > > > than than GitLab. GitLab is designed as a place to do interactive > > > work, not to keep a reliable permanent record. > > > > The git repositories, sure. The git forge? I don't see why. You can > > have these repositories in a separate namespace, which sets strong > > branch and tag protection rules to achieve what you describe. As far > > as I am aware, this is possible to do in Salsa already, it doesn't > > have to be a per-forge rule, it can be per-namespace, I think this is > > possible to achieve in Gitlab. I have not used tag protection rules > > (on gitlab, I used them on github though), but I do regularly use > > branch protection rules on my Salsa repositories. > > > > To be clear, I am exclusively talking about the git forge, as in > > salsa.debian.org, not the git repositories as they might exist on > > Salsa under the debian/ namespace or any other namespace. > > > > Having a separate namespace with strong ACLs seems exactly what you > > want, even if it duplicates the individual repositories (the backend > > git store deduplicates it anyway, so in practice it should be quite > > cheap). Having an entire separate git forge that competes with Salsa > > seems orthogonal to this, and counterproductive for the project. > > I fail to recognize how strong ACLs achieves exactly the same separate > storage on a separate host. Especially when the purpose is to minimize > attack vectors.
As per the security review just shared, admin access to Salsa allows to push commits anyway which would get uploaded just the same, and again as per security review, this case benefits from centralizing: one host to maintain, and one set of admins to trust, is better than two. Especially as Salsa is Gitlab, which is maintained upstream and benefits from the many-eyes-and-many-users situation, while a completely custom local git forge reimplementation, other than inevitably suffering from bitrot at some point in the future, like all custom infrastructure, will have the disadvantage that nobody else uses it. This is the reason Alioth is gone, and it's a very good reason. > > > That Git archive is not parallel to or competitive with Salsa and doesn't > > > provide most of the functionality that Salsa does. It has a different > > > purpose. > > > > I disagree strongly. As we have seen in the recent Salsa thread on > > d-private, there are a few but very strongly opinionated people who > > are vehemently against Salsa and would like to see it gone. Having a > > parallel and competing git forge I fear would give them very strong > > ammunition to do so: "if the real uploads and the real repositories > > are on a separate and independent git forge, why have Salsa at all? > > Get rid of it and use the other forge exclusively." > > I don't follow d-private, but sounds to me like that argument goes both > ways - i.e. also "if the real uploads and the real repositories are on > (some specially locked down section of) same git forge, why not embrace > additional features offered from same vendor of said forge?" I don't follow, we already use features from Salsa? Like the CI pipeline, which is awesome. ACLs on repositories are not really unique or particular to Github, modern forges pretty much have to support them, Github has them too.
