On 17258 March 1977, Luca Boccassi wrote:


"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."

So I don't think this is a good argument. One system is better than
two. And we need to secure all of it anyway, as Salsa is a component
of the solution anyway.

Nah. Without having looked through the dgit source - having a system
beside salsa do this for Debian is much preferable.

The gitlab for salsa is
a.) forcing us to follow a way that does *not* fit how Debian works for
uploads
b.) a codebase so much larger and made out of so many more components
than all of this proposals code combined together, it will be *worse*.
I mean, look at the security history of Gitlab. Sure, they are fast in
fixing. But they are *constantly* fixing things up with "critical
release, apply ASAP".

While I haven't had the time to look in detail into this
dgit/tag2upload/whatever thingie, I am happy it is separate. If it's
able to integrate with Salsa (or any forge) by, say, receiving webhooks
or something (or just reading from it), thats the interface I would like
it to have. Nicely separate, but interacting.

Has another advantage: Makes it easier to switch away from gitlab to
whatever other forge we may want to switch to, at some point. I'm sure
it will happen at some point that gitlab won't fit us anymore.

--
bye, Joerg

Reply via email to