apt behaviour when package with strict dependencies rules and version -gt in -updates than -security.

[Eric Desrochers]

[Impact]

We notice that situation while investigating a security update using Landscape, but it also applies to 'apt' outside the Landscape context.

'apt' should be smarter to detect/install packages with strict dependencies such as systemd[1] when a version is specified for upgrade (Ex: $ apt-get install systemd=229-4ubuntu-21.1).

It should automatically install the dependencies (if any) from that same version as well instead of failing trying to install the highest version available (if any) while installing the specified version for the one mentionned :

========================
$ apt-get install systemd=229-4ubuntu-21.1
....
"systemd : Depends: libsystemd0 (= 229-4ubuntu21.1) but 229-4ubuntu21.4 is to be installed"
=========================

To face that problem :
- Package with lower version should be found in -security ( Ex: systemd/229-4ubuntu21.1 )
- Package with higher version should be found in -updates ( Ex: systemd/229-4ubuntu21.4 )
- Package should have strict dependencies ( Ex: libsystemd0 (= ${binary:Version}) )
- The upgrade should only specify version for the package, without it's dependencies. (Ex: $ apt-get install systemd=229-4ubuntu-21.1" #systemd without libsystemd0 depends)

Using systemd is a good reproducer, I'm sure finding other package with the same situation is easy.

It has been easily reproduced with systemd on Xenial and Bionic so far.

[1] debian/control
Depends: ${shlibs:Depends},
${misc:Depends},
libsystemd0 (= ${binary:Version}),
...

[Workaround]
If package + dependencies are specified, the upgrade work just fine :

Ex: $ apt-get install systemd=229-4ubuntu-21.1 libsystemd0=229-4ubuntu-21.1

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Eric Desrochers (slashd)]

Another package scenario, using "zsh" this time:

$ apt-get install zsh=5.1.1-1ubuntu2
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 zsh : Depends: zsh-common (= 5.1.1-1ubuntu2) but 5.1.1-1ubuntu2.2 is to be installed
E: Unable to correct problems, you have held broken packages.

I'm currently compiling the 'apt' upstream source code to test using the latest and greatest 'apt' version and see by any chance if that behaviour is still present using latest version.

[Eric Desrochers (slashd)]

Same thing using upstream 'apt' release on : Mon Aug 20 17:44:39 2018

# ./cmdline/apt-get -v
apt 1.7.0~alpha3 (amd64)

# sudo ./cmdline/apt-get install zsh=5.1.1-1ubuntu2
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 zsh : Depends: zsh-common (= 5.1.1-1ubuntu2) but 5.1.1-1ubuntu2.2 is to be installed
E: Unable to correct problems, you have held broken packages.

[Julian Andres Klode (juliank)]

I disagree. Being strict about the policy is a good thing - it gives you a predictable result.

That said, you could install zsh/release and that does do some switching of candidates to make that work. I don't like that. It also does not work entirely reliably. I just closed two or three of these bugs as Won't Fix or Invalid or something.

One exception I'd consider to be a valid thing is to switch candidates of packages from the same source package, but that only helps for a limited number of problems.

We are in desperate need of a new solver, and I hope to get https://salsa.debian.org/apt-team/apt-solver-kalel/ working eventually. But even there, by default, we're strict about policy. You'd get an option to relax policy and determine a best solution where there is no strict solution available. But that should require an explicit opt-in.

I do not plan to backport that solver to older releases, except as an EDSP (external dependency solver protocol) solver. But solvers like that are remarkably slow.

[Julian Andres Klode (juliank)]

The solver in EDSP form is intended for use by autopkgtest, as autopkgtest really needs the ability to install stuff from proposed as needed. It won't make for a general purpose solver.

[Julian Andres Klode (juliank)]

So the problem seems to be that landscape assumes that upgrading a binary package with the same name as a source package yields a usable result, instead of querying which binaries are installed from that source and upgrading them.

Like source systemd has systemd and libsystemd, so we should have a request to upgrade both of them. Or assume source foo builds foo-bin and libfoo.

[Eric Desrochers (slashd)]

In the attempt to workaround that behaviour at least for Landscape USN.

Would it be doable to force the package upgrade in Landscape by pocket instead of package version ?

Fetching the package list from the USN file, then instead of ordering a specific version, just mentioning where to go to find the package.

Ex:

apt-get install -t xenial-security systemd

instead of

apt-get install systemd=<VERSION>

- Eric

[Eric Desrochers (slashd)]

# apt-get install --dry-run -t xenial-security systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libpam-systemd libsystemd0
Suggested packages:
  systemd-ui systemd-container
The following packages will be upgraded:
  libpam-systemd libsystemd0 systemd
3 upgraded, 0 newly installed, 0 to remove and 221 not upgraded.
Inst libpam-systemd [229-4ubuntu7] (229-4ubuntu21.1 Ubuntu:16.04/xenial-security [amd64]) []
Inst libsystemd0 [229-4ubuntu7] (229-4ubuntu21.1 Ubuntu:16.04/xenial-security [amd64]) [systemd:amd64 ]
Conf libsystemd0 (229-4ubuntu21.1 Ubuntu:16.04/xenial-security [amd64]) [systemd:amd64 ]
Inst systemd [229-4ubuntu7] (229-4ubuntu21.1 Ubuntu:16.04/xenial-security [amd64])
Conf systemd (229-4ubuntu21.1 Ubuntu:16.04/xenial-security [amd64])
Conf libpam-systemd (229-4ubuntu21.1 Ubuntu:16.04/xenial-security [amd64])

# apt-get install --dry-run systemd=229-4ubuntu21.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 systemd : Depends: libsystemd0 (= 229-4ubuntu21.1) but 229-4ubuntu21.4 is to be installed
           Recommends: libpam-systemd but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

[Simon Poirier (simpoir)]

That workaround wouldn't work in Landscape for many configurations; we can't assume pocket names as many use custom mirrors or repository snapshots in which the pocket may not match.

It seems to me there is no simple way to resolve this automatically in Landscape, but as that upgrade situation is both infrequent, noisy, and is easy to resolve manually, the real workaround for landscape is to install those versions manually when that case happens.

Other than that, managing sources lists to limit them to -security after deployment is the only other simple way to ensure that situation does not happen with landscape.

[Julian Andres Klode (juliank)]

FWIW, the real approach would be to follow unattended-upgrades and write a GPLed script that uses python-apt and adjusts the candidates. Then (copy and? - no real idea how landscape works) invoke that on the system.

[Eric Desrochers (slashd)]

Then if 'apt' nor 'landscape' can't have viable change. The only other workaround I can think of would be to modify the way USN database pickle works to include dependencies for package with USN vulnerability to avoid this situation like this at least for dependencies within the same source package.

Example :
In this case, if instead of only flagging systemd, the USN was also flagging libsystemd0 (part of the same source package) the problem wouldn't have happen.

I would like to have security thought about this ?

- Eric

[Julian Andres Klode (juliank)]

Again: The security notice is about source packages, not binary packages. libsystemd0 and systemd are both part of the systemd source package, so obviously both need to be upgraded if installed.

[Eric Desrochers (slashd)]

Thanks for the clarification Julian.

[David Coronel (davecore)]

There is a similar situation where apt-get wants to remove packages when strict dependencies (equal version number) cannot be met. For example dovecot-core/dovecot-pop3d/dovecot-imapd.

After installing Ubuntu 16.04.3 LTS from the ISO, install the 3 packages from the release pocket:

$ sudo apt install dovecot-imapd=1:2.2.22-1ubuntu2 \
    dovecot-core=1:2.2.22-1ubuntu2 \
    dovecot-pop3d=1:2.2.22-1ubuntu2

USN-3587-1 [1] wants dovecot-core to be upgraded to 1:2.2.22-1ubuntu2.7

Trying to upgrade dovecot-core to 1:2.2.22-1ubuntu2.7 will want to remove dovecot-imapd and dovecot-pop3d:

$ sudo apt-get install --dry-run dovecot-core=1:2.2.22-1ubuntu2.7

Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  ntp dovecot-gssapi dovecot-sieve dovecot-pgsql dovecot-mysql dovecot-sqlite dovecot-ldap dovecot-imapd dovecot-pop3d dovecot-lmtpd dovecot-managesieved dovecot-solr
The following packages will be REMOVED:
  dovecot-imapd dovecot-pop3d
The following packages will be upgraded:
  dovecot-core
1 upgraded, 0 newly installed, 2 to remove and 171 not upgraded.
Remv dovecot-imapd [1:2.2.22-1ubuntu2]
Remv dovecot-pop3d [1:2.2.22-1ubuntu2]
Inst dovecot-core [1:2.2.22-1ubuntu2] (1:2.2.22-1ubuntu2.7 Ubuntu:16.04/xenial-security [amd64])
Conf dovecot-core (1:2.2.22-1ubuntu2.7 Ubuntu:16.04/xenial-security [amd64])

Why? The only package that is *required* to be upgraded (because the USN specifies it, and because we currently treat USN package specs as binary packages), is dovecot-core. Apt's (simple) dependency solver figures it can upgrade that, but in doing so it breaks dovecot-imapd and dovecot-pop3d which need removing as a consequence. The workaround is to specify all 3 packages:

$ sudo apt-get install --dry-run dovecot-core=1:2.2.22-1ubuntu2.7 \
    dovecot-imapd=1:2.2.22-1ubuntu2.7 \
    dovecot-pop3d=1:2.2.22-1ubuntu2.7

Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  ntp dovecot-gssapi dovecot-sieve dovecot-pgsql dovecot-mysql dovecot-sqlite dovecot-ldap dovecot-lmtpd dovecot-managesieved dovecot-solr
The following packages will be upgraded:
  dovecot-core dovecot-imapd dovecot-pop3d
3 upgraded, 0 newly installed, 0 to remove and 171 not upgraded.
Inst dovecot-pop3d [1:2.2.22-1ubuntu2] (1:2.2.22-1ubuntu2.7 Ubuntu:16.04/xenial-security [amd64]) []
Inst dovecot-imapd [1:2.2.22-1ubuntu2] (1:2.2.22-1ubuntu2.7 Ubuntu:16.04/xenial-security [amd64]) []
Inst dovecot-core [1:2.2.22-1ubuntu2] (1:2.2.22-1ubuntu2.7 Ubuntu:16.04/xenial-security [amd64])
Conf dovecot-core (1:2.2.22-1ubuntu2.7 Ubuntu:16.04/xenial-security [amd64])
Conf dovecot-pop3d (1:2.2.22-1ubuntu2.7 Ubuntu:16.04/xenial-security [amd64])
Conf dovecot-imapd (1:2.2.22-1ubuntu2.7 Ubuntu:16.04/xenial-security [amd64])

[1] https://usn.ubuntu.com/3587-1/

[Julian Andres Klode (juliank)]

All I can say: If you treat USN reports as binaries then you are definitely missing security updates.

[Julian Andres Klode (juliank)]

I mean, consider the apt one. It lists apt, but the fix is in the binary libapt-pkg5.0.

I assume you can specify --only-upgrade or what it's called too to prevent removals (but also new installs). In any case, there is no solution here.