On 07/15/2014 02:11 PM, Michael Stone wrote: > On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote: >> How do you propose managing a distro that mostly needs apt as is, but other >> times need "Acquire::Check-Valid-Until off;"? In other words, how would you >> manage a distro that sometimes uses apt as it was designed, and other times >> has to tweak in ways that would break the main use case? That sounds like a >> recipe for lots of edge cases and bad bugs. > > Um, so does your suggested change. Using apt with the valid check off is > fundamentally equivalent to using signed .debs. Both mechanisms have the same > failure modes, but one is a configuration change and one reworks the trust > path to get to the same place. >> is up-to-date, downloaded packages are intact, etc. Then the moment of >> install would use the signature in the .deb to verify that the .deb is intact >> and signed by a trusted key. Right now, `dpkg -i package.deb` does not >> verify >> against any signature. > > This is funcationally the same thing as checking that the hash of the deb is > the same as the one listed in the Releases file (or apt-cache show) before > installing the deb. You could do that in a wrapper. > >> So for the offline system, if the .deb files have signatures, the .deb files >> can be copied on the offline machine however (apt-offline is a good option, >> but others are possible), then they can be installed, uninstalled, etc. after >> verifying that the signature in the .deb is trusted. So really, this would >> not be modifying apt so much as modifying `dpkg -i`. > > Right, as I said, a complete reworking of the trust path (new code, new bugs, > etc.) to get essentially the same result. It sounds like what you need to do > to get the result you're talking about is grab the releases file along with > the deb, validate the sig on the releases file (except ignoring the > expiration), verify the hash of the .deb, then install the .deb. Depending on > the specifics of the implementation you could do that from an apt command line > by setting the Check-Valid-Until via -o > or by writing a dpkg wrapper. In any event it shouldn't be all that much code > and certainly much less what you're proposing. (I'd also hope that your front > end would at least tell the user how old the Release file is, and that the > distributor recommends checking for a newer version. The expiration mechanism > is important to ensure that people aren't installing old/vulnerable versions > of trusted packages--which may be equivalent to installing trojan packages.) > > Mike Stone
There is already an existing format for signing and verifying .debs, the signing keys infrastructure is already in place, there is a clear spot to validate on install, doing some hacked together dpkg wrapper sounds like a good way to prototype, but a bad way to widely deploy a working system. I'm not saying that adding .deb signature validation to `dpkg -i` would be trivial and without risk. But the idea of validating signed package files on install is hardly revolutionary or even novel any more. Indeed it is pretty widespread: think Android, Fedora, Java, iOS, etc. I think it is the cleanest approach for the problem that I've outlined. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c58e06.3030...@at.or.at