[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-sig support wanted?

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

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.


Attachment: signature.asc
Description: Digital signature

Reply to: