On 07/14/2014 01:57 PM, Michael Stone wrote: > On Mon, Jul 14, 2014 at 01:22:10PM -0400, Hans-Christoph Steiner wrote: >>> Or, you could make use of the Check-Valid-Until and Min-ValidTime options in >>> apt.conf. There's a reason things are done the way they are, and you >>> probably >>> aren't going to find a lot of interest in getting people to do a lot of work >>> to create a system which is duplicative at best and less secure at worst. >> >> Sure, those options would work well for people who understand them and want >> to >> tweak them. I'm not interested in that. I'm currently working on a >> TAILS-based system for running build and signing processes on machines that >> _never_ go online. So that means that changing the apt config is not an >> option. I'm working with apt-offline currently and that helps a lot. > > You're making an assertion and not supporting it. Changing a configuration > parameter is unacceptable, but switching to an entirely different package > trust model is ok? You care very much about the trust path to debian packages > but not anything else (like the software that's installing them?) Seems like a > weird problem, but maybe you're just not fully explaining it. If that's really > the constraint set I guess it may be a case of "you created your problem, so > you get to fix it". > >> TAILS is a live CD, but provides a method of installing and maintaining new >> packages on top of what is provided by the live CD. That means those >> packages >> are stored in an encrypted stash, and are installed on each boot. So in >> order >> to use this feature, the apt cache needs to be refreshed using apt-offline at >> least every two weeks, otherwise the packages won't be installed since apt >> can >> no longer validate them. > > Have you actually tried setting "Acquire::Check-Valid-Until off;" in apt.conf? > What was the result?
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. The situation in TAILS in not like normal Debian installed, but it basically the same for any live CD that has the option of installing additional packages from a persistent store. TAILS is mostly meant to be on online system, but fully offline support is in the works. Having signatures in .debs is entirely complementary to the existing apt system. It does not change how apt works at all in the normal network mode. The apt metadata would be used to verify that repo information 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. 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`. .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/53c564a8.4000...@at.or.at
