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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]