Hi, 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 signaturesin 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 thearchives 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 signature...
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 reasonable.
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.
Simon
Attachment:
signature.asc
Description: OpenPGP digital signature