Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 22:26, Jonas Smedegaard <jonas@jones.dk> wrote:
>
> Quoting Luca Boccassi (2024-06-12 22:00:04)
> > On Wed, 12 Jun 2024 at 15:20, Jonas Smedegaard <jonas@jones.dk> wrote:
> > >
> > > Quoting Luca Boccassi (2024-06-12 15:27:36)
> > > > On Wed, 12 Jun 2024 at 14:15, Jonas Smedegaard <jonas@jones.dk> wrote:
> > > > > You apparently find it equally sensible, specifically as a security
> > > > > measure, a) apply ACLs on an otherwise massively multi-user-write-access
> > > > > host and b) use a separate far-less-featured host.
> > > > >
> > > > > You claim that both setups have equal vulnerabilities.
> > > >
> > > > No, I claim they have different sets of vulnerabilities, disadvantages
> > > > and advantages, and that both can provide the required feature:
> > > > disallow force pushes/deleting tags. The hardest thing with security
> > > > is that it requires a constant, ongoing effort, that will never end,
> > > > and will only get harder. A widely used software like Gitlab is better
> > > > for this, as is a widely used kernel like Linux. Or are you suggesting
> > > > such a server should run on Hurd, given it's far-less-featured and
> > > > thus has a much smaller attack surface than Linux?
> > >
> > > No, I am not suggesting the use of the Hurd here, and I am having a hard
> > > time assuming good faith with the potential undertones of that question.
> > >
> > > To answer your convoluted question, I am suggesting that Salsa and
> > > tag2upload has very different needs (multi-user write versus multi-user
> > > append-only, drastically simplified), and consequently to not argue that
> > > reuse of Salsa for hosting tag2upload is a security benefit.
> >
> > The argument is about attack surface, number of features, size of code
> > base, auditability, etc. If you make that argument about the git stack
> > running on a server, then the same argument applies for every other
> > component in the same server that interact in any way with the
> > payload(s) - kernel, libc, compilers, etc. Otherwise you are just
> > cherrypicking what is convenient, and ignoring what is not. If Gitlab
> > can't be used in a security-relevant component because it's too big to
> > audit, then so are the Linux kernel and GCC.
>
> My point above, reframed to your new context, is that regardless of how
> overwhelmingly large the attack surface of GCC+linux is, the attack
> surface of GCC+linux+Gitlab is much larger, while that of
> GCC+linux+tag2upload is little larger.
The attack surface of GCC+linux+tag2upload is orders of magnitude
larger than that of TCC+hurd+tag2upload. Are you going to advocate for
that switch to happen? If not, why? Why do you think it's worth to
deprecate Salsa because of its much larger attack surface, but it's
not worth deprecating Linux and GCC for their demonstrably much larger
attack surfaces? Could it be, maybe, perhaps, that a superficial
comparison of perceived attack surfaces alone is not really a good
metric to make a decision?
> > My argument is that having a single system is beneficial for
> > maintenance costs (fewer platforms, fewer moving parts), for security
> > (components in widespread usage with heavy commercial backing spending
> > the big $$$$ to ensure it's not completely borken), and for
> > rationalizing and avoiding duplication.
>
> Ok, if your argument is no longer that "the same setup can be achieved
> with repository ACLs, and it would have the same vulnerability" but that
> security+economy+maintenance combined makes your previous security-only
> point less relevant to discuss, then I have nothing sensible to
> contribute to this new path of yours.
My argument has always been the same, which is: a custom forge is not
needed to satisfy the requirement that force pushes/deleting tags is
disallowed to users, which is what the design document uses to justify
its choice as I understand it. If you understood something else from
my point, then I'm afraid you were simply mistaken.
Reply to: