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

Re: dpkg-sig support wanted?


Anthony Towns wrote:

The problem is that using gzip and ar is complicated, which adds
possibilities for errors. You might find yourself not putting the deb
together again and getting false signature mismatches, or worse, you
might find yourself only verifying part of the .deb, and having dpkg
actually use parts of the .deb that haven't been authenticated under the
false conviction that you're actually safe. With "md5sum foo.deb" you
know you've authenticated everything.

Which is also a disadvantage in some cases. I could see a case for extending .deb files (say, with additional translations for the description and templates, thus removing the need for the maintainer to reupload new packages when new translations are ready).

I think that it should be fairly easy to implement something that can verify parts of .deb files and check whether the authenticated parts together form a complete and consistent package on their own.

This thread, however, is not about a technical problem, so I would propose a sauna meeting.

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),

That is already possible with gnupg, just not well-documented; I'm not entirely sure what interesting breakage would occur if one were to upload a changes file with multiple signatures.

and also that the .changes file will be stored in the
archives along with the .debs,

As it turns out, that's probably not feasible per se -- it likely implies
too much inode usage, and slack space.

And is probably pointless. If you don't trust the Debian infrastructure, you are free to get the source (which is signed by the maintainer) and build the package yourself.

where dpkg would simply refuse
per user-set policy any non-signed deb or any deb without a specific

I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting
a signature by a random Debian developer to mean something is not

That's why there can be multiple signatures. There would be one from the maintainer/buildd, a few from the Debian archive (for example, you could add one sig for "officially in Debian unstable", one for "migrated to testing" and one for "in a stable release") and if the idea of adding description/template translations later on catches on, also some from the translators/translation system.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: