Re: tag2upload service architecture and risk assessment - draft v2
PS: Please stop sending my copies of e-mails, I explicitely ask not to
by specifying Mail-Followup-To.
Hi Ian
On Wed, Aug 28, 2019 at 12:10:44PM +0100, Ian Jackson wrote:
> Tracing the archive contents back to uploader signatures is already
> complicated because of the difficulty of understanding what an
> appropriate maintainer signing key is for any particular .dsc.
I have no idea what you are talking about. We have keyrings, we have
other information. If the .dsc is signed by a person, you can verify
it.
> With
> my proposal it indeed becomes more complicated.
Then make it less complicated?
> But I have to ask:
> Is the uploader signature on the .dsc really the thing we want to
> trace the .dsc back to ? Usually nowadays the uploader .dsc signature
> is made on the output of some git-buildpackage rune (or automatically,
> by that rune).
Yes. So he certifies that he wants to upload exactly this version of
the code, not something else. And that is exactly what we are talking
about: do we have exactly the same source as intended by the uploader.
> Typically the human uploader doesn't intend to release some particular
> .dsc; that's an output artefact. The uploader intends to release some
> git commit.
No, he wants to release a particular version of the code. Git is just a
transport medium.
> So the .dsc should be traceable to that git commit. Currently it is
> not. With my proposal the .dsc is traceable to the git history,
> including the uploader's signed tag.
Well, providing this information just needs another field in the .dsc,
not overall changes in the process.
Bastian
--
There are always alternatives.
-- Spock, "The Galileo Seven", stardate 2822.3
Reply to: