On 07/16/2014 08:06 AM, Holger Levsen wrote: > Hi, > > On Mittwoch, 16. Juli 2014, Michael Stone wrote: >> Yes you are--what you described is exactly how the Release files work. > > Well, there are (many) other .debs on the net which are not part of our > releases, so it still seems to me that making .changes files accessable in > standardized ways could be very useful. What I'm talking about already exists in Debian, but is rarely used. dpkg-sig creates a signature that is embedded in the .deb file. So that means no matter how the .deb file got onto a system, that signature can be verified. I'm proposing to start making dpkg-sig a standard part of official .deb files. This can be done in stages to make it manageable. Here's a rough idea of that: 1. Adding a 'builder' signature should be easy to start with, make `debsign` also run `dpkg-sig --sign builder` on any .deb files it finds. I believe that `dpkg -i` will already try to verify a signature if it exists. 2. add something like `dpkg --require-debsig` to force checking of the dpkg-sig signature. This would be optional to start with, and complimentary to the already existing `dpkg --no-debsig`. 3. make `dpkg-buildpackage` call `dpkg-sig --sign builder --sign-changes full` to sign packages. 4. etc. As for Michael's complaint that I have not described a real problem, I have tried already in the thread, so I'll try again in bullet points: * TAILS is a Debian-based live CD * the core system image by definition cannot be modified (live CD) * it has a feature for persistent storage of files on a USB thumb drive * it also can save apt cache/lib to that persistent store * it will automatically install packages on boot from that store * mostly people use TAILS in online mode * there is a fully offline mode in development * offline TAILS cannot verify the packages if apt lists are > 2 weeks * updating the apt cache/lib is painful on an offline machine * an offline machine's threat model is drastically simpler On top of all that, each update increases risk of compromise on offline machines because each new update provides a vector to run a script or introduce new code that otherwise does not exist (no network!). And any decent attacker with physical access to the machine will always get in. Other people want to be able to directly download .deb packages and have then verified as part of the install process. This is not my primary concern, but I do think it is a valid one. It would also be addressed by fully support of dpkg-sig. .hc
Attachment:
signature.asc
Description: OpenPGP digital signature