Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 12:03, Jonas Smedegaard <jonas@jones.dk> wrote:
>
> Quoting Luca Boccassi (2024-06-12 12:28:21)
> > On Wed, 12 Jun 2024 at 09:35, Jonas Smedegaard <jonas@jones.dk> wrote:
> > >
> > > Quoting Luca Boccassi (2024-06-12 10:21:40)
> > > > On Wed, 12 Jun 2024 at 02:31, Russ Allbery <rra@debian.org> wrote:
> > > > >
> > > > > Luca Boccassi <bluca@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.
Reply to: