Quoting Luca Boccassi (2024-06-12 12:28:21) > 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.
So your argument is that that strong ACLs achieve exactly the same as separate storage on a separate host, because separate storage on a separate host inevitably leads to bitrot and lack of eyeballs. I rest my case. > > > > 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. Sorry, I cannot possibly get a point across a cloud of awesomeness. - 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
