[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apt for jessie



On 17/10/14 19:56, Michael Vogt wrote:
Dear Release Team,

we - the APT team - would like to ask for permission for a transition,
namily of the apt version as found in experimental to unstable with
the target of reaching jessie.

While it adds some long requested new features
(like apt-get install foo.deb & apt-get build-dep foo.dsc),
the most important changes are security improvements:

* apt-get source uses all hashes, not just MD5 for verification
* .pdiff/Index parsing is prepared to pick up others than just SHA1
* most acquire methods, most importantly http, are running now as the
   new system user _apt, which is allowed to write to our partial/
   directories only, rather than as root doing potentially everything
   (and to every file)
* the acquire system itself is made more resistent to inconsistent
   states recieved from mirrors (or MITM). At the moment apt would
   mix new and old data in case of hashsum mismatches for example,
   while it now has a proper all or nothing approach by properly
   tracking which files should move together.
* signed repositories are no longer allowed to change to an unsigned
   state, preventing us from being effected by downgrade attacks
* acquire methods are told what the expected size is, so that they can
   protect themselves from DoS attacks sending e.g. an endless stream
   of zeros to the method filling up the disk.
* if we have them (e.g. in the Release file) we always validate the
   compressed file we downloaded, too, instead of just validating the
   uncompressed file with the included hashsums.
* allows to completely disable the use of "insecure" (aka unsigned or
   signed, but with unknown keys) repositories

The later is hidden behind Acquire::AllowInsecureRepositories, which
at the moment defaults to "true" to give external repositories a
certain grace period, but we intend to switch to "false" for jessie+1.
(That is, if you don't think it would be a big problem, we would love
to flip the switch also now… ;) )

We understand that we are very very late in the release process to
suggest this, but we have the strong believe that these improvements
are well worthed the incurred risks – also because one of the reasons
this is so late is that we had to deal with multiple CVEs discovered
in the process of implementing this.

This is "only" an ABI break and correctly tracked by the auto-apt
transition [0] for a while now. Michael tried recompiling the packages
listed there and can confirm this in so far as only libept (which
contains libapt-pkg's soname version in its binary package name, so
package needs to be slightly adapted and travel through binary-NEW)
and python-apt (which needs to be adapted slightly in its c-bindings
for the LFS in libapt-inst) need more than a binary rebuild against
the new version.

I think it's too late for this.

Emilio


Reply to: