Re: [RFC] General Resolution to deploy tag2upload
Hi,
On Wed, 2024-06-12 at 06:25 +0800, Sean Whitton wrote:
> As tag2upload is security-sensitive, the design has had careful,
> independent security review from Russ Allbery and Jonathan McDowell,
As I said several times before: the implementation has known security
bugs (unless you fixed them). But I guess this is going to get ignored
again anyway... Reviewing the design doesn't help with this.
In addition it reintroduces trust in weak cryptographic hashes which
effort was spent to remove.
> ftpmaster stated a hard requirement that dak has to be able to
> completely re-perform the verification of maintainer intent done by the
> tag2upload service. That goal cannot be met without fatally undermining
> the tag2upload design and user experience.
That's not the only issue. Known security issues are another.
In addition from the history of WebPKI compromises, it should we well
understood that having several paths to certificate issuance is not a
good idea. Several paths to introduce source to Debian has similar
problems.
> THE DESIGN & IMPLEMENTATION ARE LATE-STAGE
>
> We wish to be clear that tag2upload can be deployed without *any*
> code changes to dak. It just needs to be given a suitably trusted
> key, very similar to how buildds have trusted keys.
And we also remove the Debian Maintainer role as dak would no longer
know who uploaded the package? Debian is larger than only Debian
Developers.
> Should this GR pass, then the tag2upload project will be unstuck, and
> could be deployed in a matter of months, and the source-only uploads
> of
> as many of us who want it can become just 'git debpush' and done,
> without any other workflow changes or learning.
If only one could use regular git instead of a custom, non-standard VCS
built on top of Git that makes some workflows impossible and team
maintenance harder by not supporting publishing intermediate work. :-(
Ansgar
Reply to: