Hi, Luca Boccassi <bl...@debian.org> wrote on 12/06/2024 at 13:15:47+0200:
> 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. Note: this is my personal PoV, I've not discussed it with my teammates. From a DSA point of view, (all of this will be Debian infra), considering what GitLab is, how much trouble it can cause and how resilient we expect our upload stack to be, I would not use it for tag2upload. (And yes, I still enjoy having gitlab, but let's be realistic about infrastructure aspects) For the rest, I have a hard time being eager to overrule FTP Masters via a GR. -- PEB
signature.asc
Description: PGP signature
