Re: concrete steps for improving apt downloading security and privacy
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`.