On Fri, Nov 25, 2005 at 02:27:23PM -0200, Henrique de Moraes Holschuh wrote: > Well, the email about the new bin-NMU structure implied that it was fixed > for *NMUs done through that structure*. Then the email was wrong. *shrug* > > > > 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. > > Uh, no, .changes files are not remotely useless for Debian right now. > > Where would you get that idea? > I was refering to "Debian has too many sources for packages for key > management to be plausible". Duh, obviously .change files are useful for > Debian, DAK needs them. Then my comment doesn't "appl[y] to .changes files too". > > The tools are the least concern; what's a few dozen lines of code here > > and there matter? If you insist every package only be uploaded once, and > > do the maximum packages per day, and stop all other development just to > > get deb sigs done, it's roughly half a year before that's finished. New > > packages, bug fixes, new upstream versions will make it take longer. > Who said anything about adding in-deb sigs to the entire archive? If they provide a useful service, then of course they should be everywhere. If they don't provide a useful service, why should they be anywhere? The dak check, for reference, is the one that authenticates an ar's in the correct form, it's not an explicit "we had dpkg-sig" check. > If I want dpkg to always check a signature, it is because it is a signature > I know must be there. Like an hypothetical signature added by > DAK/dinstall/whatever, or a signature I add to all debs in a specific > repository under my control (and in this case, with a timestamp under my own > control too, which means I can use it). Again, what you do in your own repositories is _fine_. .deb signatures are a completely useful thing to do in some circumstances; which I'm inclined to classify as "private development / public release". Debian just happens not to be in that problem space. > > a signature by a random Debian developer to mean something is not > > reasonable. > YOU are the one who is bringing in signatures from j.random developer. Uh, no, it's what this thread's about. You know, random developers uploading signed packages to the archive...? > > I'm tempted to do something like that anyway to see if the md5sum > > exploit can be used to create fire and ice .debs. Without signed debs, > Make that an exploit that says "kaboom, you're it" but still runs dpkg, and > I will help you with it. ATM I've got better things to do. But xmas is coming up, with the corresponding need for a pointless xmas project... > > The explanation you need is "...which is useful because _____". Again, I > > can't see any need for multiple signatures for Debian; for non-Debian, > > if deb sigs are convenient, use them. > deb sigs get a lot less convenient if Debian doesn't allow them in debs > uploaded to the archive. How so? Seriously -- add the signature after uploading to Debian. At worst, if you have a deb that's in both Debian and some other source, you might end up installing the unsigned .deb from Debian instead of the signed version -- but you've still verified it just like every other Debian package, so... big deal? If you set up apt's pinning correctly, that won't even happen. Cheers, aj
Attachment:
signature.asc
Description: Digital signature