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. > > 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?" - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
