On 17258 March 1977, Sean Whitton wrote:
So, why am I proposing a GR?
This one took me by surprise, honestly.
Looking into my notmuch, the last time tag2upload came up in my
ftpmaster inbox was in 2019. Between then and now there doesn't appear
to
be any serious contact with us about it. There had been mentionings on
some mailing list somewhere, but nothing coming to us, that I can find.
Even then, back in 2019, one of the major points that ftpteam members
raised had been "the archive has to be the final point to check if an
upload is accepted" and that we do retain *all* user signatures of
source packages, and that such a service must provide the same level of
possible verification. Some other requirements on the signature too
(collision resistant, need to be verifyable with only stuff included in
the source package). Also something about not using Perl, but meh, lets
ignore that one here.
So, 5 years of (hopefully) development, but the major point (this should
*not* bypass/circumvent archive upload checks and restrictions) did not
get addressed. More like, entirely ignored.
Or, in your own words: fatally undermining the archive/daks design and
user experience.
The ftpmaster team have refused to trust uploads coming from the
tag2upload service. This GR is to override that decision.
Really. Tell you what: FTPMaster is in favor of tag2upload and would
like to see it running. Just not in exactly the way it is currently
designed.
While we want people in Debian in critical paths for archive security
to
be relatively conservative, that conservatism can be taken too far,
and
we think that is what has happened in this case.
While we want people developing new tools for Debian to be relatively
open and experimenting with new ways, those new ways can be taken too
far and ignore input and experience from those running existing
services, and we think that is what happened in this case.
Now we each had some of those words, can we leave that out, and actually
see of getting this included usefully?
In fact, tag2upload significantly *improves* the traceability of our
source-only uploads.
It significantly breaks existing checks and procedures.
Now, I do like a future of "git $something" and out pops a Debian
upload. Others do too.
We had a bit of a chat in our ftp channel (as you may know, if reading
irc), so let me summarize something we see as a way forward:
FTPMaster *is* in support of t2u, if it ends up in a way that allows
dak doing the final verification/authorization of the upload, NOT
needing to trust some other instance.
As generating changes and dsc on the maintainer side is out (we want a
git $something workflow now), that verification ought to be over the
content. So whatever tool the maintainer ends up calling ought to
generate a signature over the content of the package and put that into
git (a tag, or whatever t2u uses).
From that, t2u can do its magic, build a source package, sign that with
its key - and in the source include the full maintainer sig. Field in
.changes or extra file, doesn't matter, as long as it's included in the
upload.
That then allows dak to do what it does now and trust the thing
originates from the maintainer. And can still do all its check on the
sig (over the content).
This will allow what t2u wants to achieve: A simple, git based, upload
workflow for the developers. It will also allow what FTPMaster wants,
verification of things included in our archive back to the actual
original maintainer *without* trusting a third party.
The above is *intentionally* not hashing out the details, just a way to
go and get t2u working in Debian, without needing a GR, with support
from ftp team. Exact details (how to do signatures, which format, blah)
are for actual implementation.
--
bye, Joerg
