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