Quoting Luca Boccassi (2024-06-12 13:15:47) > On Wed, 12 Jun 2024 at 12:03, Jonas Smedegaard <jo...@jones.dk> wrote: > > > > 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. > > No, my argument is that append-only can (as far as I can tell) be > achieved on Salsa too, it doesn't seem to necessitate a bespoke forge. > The centralizing argument is not mine, it's from the security review > that was published this morning: > > "My security recommendation in this case is therefore to centralize > the risk as much as possible, moving it off of individual uploader > systems with unknown security profiles and onto a central system that > can be analyzed and iteratively improved." > > https://lists.debian.org/debian-vote/2024/06/msg00004.html > > > > > > > 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. > > "Having an easy-to-use and working CI is really bad for a software > development organization, actually" is... a bold take, no doubt about > that. > > But anyway, thanks for proving my point for me: there is a small but > loud minority who would like to kill Salsa, and this proposal as > implemented would help them achieve that goal. If it goes to a GR, > this is enough to make me vote against it, as while the concept is > really nice and I like it a lot, it's not worth jeopardizing Salsa's > existence.
Ohh, it was me you were referring to (because yes, I did read you the first time, just didn't recognize you pointing fingers in my direction). If it was me derailing this conversation, then I sincerely apologize. - 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
