Re: dpkg-sig support wanted?
On Thu, 24 Nov 2005, Anthony Towns wrote:
> You can already use release signatures for this. Further, changing the
> deb after upload would make it much more difficult to check the deb was
> what was uploaded -- you can no longer just use md5sum, you've instead
> got to use special tools.
While the point about "you can no longer just use md5sum" is useless (you
need gpg, other "special" tools won't make it any more difficult, especially
since they are gzip and ar), the point about not changing the .deb after
upload is a very good one. In fact, the only good point against in-deb
signatures I've seen so far.
> Sure; but why do that inside the .deb? You can verify a detached signature
> just as easily as an inline one (gpgv sig file // gpgv file), and you
IF this means we can switch the effort to a detached signature that is more
powerful than a .changes file (or we are allowed to have multiple signatures
in a .changes file), and also that the .changes file will be stored in the
archives along with the .debs, and that .debs with wrong/incomplete/missing
Source: fields will be rejected (such as all automated bin-NMUed .debs made
until about a week ago, or any made by a maintainer right now), and that the
path to go from the Source:-field to the .origin/.changes file name is set
in stone... then yes, detached signatures would do it.
> My objection is that it's *useless* for *Debian*. Debian has too many
> sources for packages for key management to be plausible, and keeps
This applies to .changes files too, with the aggravating addition that those
are a bitch to find right now.
> authenticated both via Packages.gz files and .changes files, which
> already exist and are usable.
ONLY if we change the way .changes files are stored. It would be best to
have them stored in the archive itself along the .debs, really, if we're
going to use them for anything other than initial acceptance through DAK.
However, integrating this on the tools will be far more difficult than an
in-deb signature (still doable, of course), where dpkg would simply refuse
per user-set policy any non-signed deb or any deb without a specific
signature...
> This is what .changes files are for, and it's useful both for recovering
> from compromises and in a "cvs blame" sort of sense. Note that they also
> give more information than a simple signature on the .deb.
Only if we can sign it multiple times, which is one of the capabilities of
the "simple signature on the .deb" we are talking about.
> Hrm, I see queue/done (which contains .changes files going back to the
> dark ages) isn't even being mirrored to merkel properly at the moment.
> That's not so constructive.
Agreed.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: