Joerg Jaspert writes ("Re: tag2upload service architecture and risk assessment
- draft v2"):
> First off: I, for personal reasons, am a bit detached right now with
> anything Debian (though that should change soon). For that reason, I
> haven't read most of the mail threads, though i skimmed over this
> one a bit.
Hi. Thanks for your attention.
> I currently do not have too deep a thought on how good their
> implementation is. Just one thing I've seen picked at multiple times,
> and in different places: The current implementation appears to move away
> the final integrity check linking an upload to a person away from the
> archive software to some other.
I don't think that's really true, although I can see why you might
think it from reading the thead. I will try to explain.
> Thats a no-go.
>
> Note: I do not say it must be "a dsc" "a git commit" or "a something"
> that is used for this check. That is an implementation detail. But the
> final check/link of an upload with a maintainer(s key) has to be "in"
> the archive. Systems before it can *additionally* do any number of them,
> but the final one is in dak.
In my proposal, as soon as dak supports it, each upload from the
tag2upload service would include a copy of the original uploader's
signed git tag object.
This would allow dak to verify the identity of the original uploader,
and the uploader's intended source package, version, suite, and
distribution; and see that they intended to use the tag2upload
service. All of that is covered by the original uploader's signature
on the git tag object and can be checked very simply without further
data. Based on what's been said in the thread I imagine that dak
would want to check all of these things.
The difficulty is that it is complicated to verify the *contents* of
the source package. (It wasn't clear to me, from your mail, whether
that is something you think is critical for dak to do.)
It would be *possible* for dak to verify the contents, since the .dscs
generated by the tag2upload service are reproducible. But it's not
easy.
Firstly, it depends on additional data: the referenced git objects
have to be obtained. (There is at least a designated place to get
them, so finding them is not a problem.)
Secondly, it is a complicated process, because it is reproducing the
complicated mapping between maintainer git branches (which may be in a
variety of forms - see my git packaging practices survey [1]) and
uploaded .dscs (which must be in a standard form).
So to do that reproduction dak would have to effectively have another
instance of the tag2upload infrastructure within it. Overall I don't
think this would make sense, even though it's possible.
I hope that clarifies things.
Thanks,
Ian.
[1] https://wiki.debian.org/GitPackagingSurvey
Not all of these are supported by tag2upload yet, but the most
common ones are. The biggest one which is missing is the monorepos.
They present additional difficulties because the maintainer tag name
must include the package name, so can't conform to standard gbp or
DEP-14 practice.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
