Re: git & Debian packaging sprint report
Hi. Not replying to things others have dealt with, but...
Russ Allbery writes ("Re: git & Debian packaging sprint report"):
> If so, I think that security model is roughly equivalent to the automatic
> signing of binary packages by buildds, so probably doesn't introduce a new
> vulnerability, but my understanding was that the identity of the signature
> on the source package was used in various other places. Presumably we
> would need to introduce some new metadata so that the uploader is mapped
> properly to the Git tag signer, rather than to some internal identity of
> the source package construction service.
I think in general those places are probably mistakes. But I'm not
aware of all of them. One way to look at this is that from the
archive's point of view this robot is a kind of sponsor. I don't
think anything will go badly wrong.
> Also, doesn't the archive publish the signed *.dsc files currently? I
> believe this would mean that we would lose some published information from
> those files that we currently have (namely which DD and which key signed
> the package, which could be useful data in some incident response
> scenarios). That said, there's been some discussion for some time about
> having the archive sign all the *.dsc files instead of keeping the
> uploader signature, which may be from an expired or unverifiable key
> (particularly for packages that haven't been uploaded in some time).
The .dsc signatures are not really useful for most practical purposes
because their validity and semantics are time-varying and only the
archive (and things which keep up to date with the archive-published
metadata) can reliably make sense of them - and even then, only at the
time of upload.
The tag2upload model of course preserves the original uploader's
identity in the form of the signature on the tag they make to instruct
the robot.
Ian.
--
Ian Jackson <ijackson@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.
Reply to: