On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote: > Then there's the opposite argument about "why not do that inside the .deb?". Simple answers: unnecessary bloat, unwarranted feeling of security leading to bad decisions. Whenever anyone asks "how do you manage the keys", the answer is usually "automatically sign by dinstall" which means the deb is modified after it leaves the builders system (invalidating existing authentication methods) and usually means changing the deb after its entered the archive (for signatures identifying packages released as part of sarge / etch, or in the case where an old key expires). > I think the final judgment in this issue is going to come down to personal > taste and needs more than anything else. That's fine for personal repositories, it's not sufficient for Debian's archive. > > > At the very least, though, I can't find a hole which makes binary package > > > signatures, done properly, any less secure than per-archive signing. > > That's easy: you trust the Packages file to be correct when using apt, > > and it's not verified at all by per-package signatures. > That's a good point. However, what damage can be done with a bodgy Packages > file, if only well-signed .debs are actually accepted for installation on > the system? Add a "Depends: some-random-package" that you know has a security hole to dpkg's entry in the Packages and it'll be automatically installed by apt. Add a "Conflicts: dpkg" to some package's entry and it'll never be installed by apt or aptitude. You can possibly be trickier by pointing apt at a completely different file too, so that the user thinks they're installing foo, but end up with bar instead only noticing if they see dpkg say "Unpacking bar (from .../foo_*.deb)". IIRC, it's tricky to make that actually work. > The only thing that comes to mind is wasting some time and > bandwidth on downloading dodgy debs (or their equally-dodgy dependencies), > but if the system checks the signatures before installing anything, can > anything actually be damaged? There are plenty of packages signed by developers, or that have been included in the archive, that have exploitable security issues. > > My objection is that it's *useless* for *Debian*. Debian has too many > > sources for packages for key management to be plausible, and keeps > > packages unchanged over too long a period for the keys to be guaranteed > > secure for the lifetime of a package. Additionally, packages can be > > authenticated both via Packages.gz files and .changes files, which > > already exist and are usable. > Don't the same arguments about key longevity apply to checking the > signatures on .changes files, too? Sure, that's why we don't encourage users to worry about them. The advantage is there's no great difficulty to providing new detached certificates with new signatures, if the need arises. The debs only need to be changed if they're actual content needs to change. (Which is also an advantage for users, who correspondingly don't have to worry about redownloading them) > > Hrm, I see queue/done (which contains .changes files going back to the > > dark ages) isn't even being mirrored to merkel properly at the moment. > > That's not so constructive. > Is there a publically accessable form of queue/done somewhere that people > can download the .changes files from? No, there isn't anything, apparently the mirroring to merkel got disabled due to the inode usage / rsync time. There's some 700k odd changes files. I think the theory is they'll start getting regularly tar.bz2'ed up and made available with an index file. > That would be quite handy for people > to use to verify binary packages (and would be a darn sight easier to use > than trolling d-d-c archives). No lie. Cheers, aj
Attachment:
signature.asc
Description: Digital signature