[Aptitude-devel] Bug#787658: aptitude ignores available updates for a while after downgrades

Sat Sep 19 11:50:55 UTC 2015

Control: tags -1 - security + moreinfo
Control: severity -1 normal

Hi all,

2015-06-03 21:48 Christoph Anton Mitterer:
>Package: aptitude
>Version: 0.6.11-1+b1
>Severity: important
>Tags: security
>
>
>Hi.
>
>The following behaviour at least for quite some time (at least several years I'd say)
>already, but so far I've always been too lazy to report it.
>
>
>Just before I've stumbled over #787653 so I tried which package upgrade could have
>caused the troubles.
>Normally I have just sid enabled in sources.list, so I've uncommented testing,
>started downgrading a few packages, tried whether evolution starts again... the usual
>game so to say.
>
>
>Now the problem from aptitude side is, that after the packages have been downgraded
>(in the example above the curl/libcurl packages) it doesn't offer them for upgrade
>anymore, even though unstable is still enabled in sources.list and the newer packages
>are still available.
>
>
>apt however, still identifies the newer one correctly as candidate version:
>
># apt-cache policy curl
>curl:
>  Installed: 7.42.1-2
>  Candidate: 7.42.1-2+b1
>  Version table:
>     7.42.1-2+b1 0
>        500 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
> *** 7.42.1-2 0
>        500 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
>        100 /var/lib/dpkg/status
>
>and it would also update it:
># apt-get upgrade --dry-run
>Reading package lists... Done
>Building dependency tree
>Reading state information... Done
>Calculating upgrade... The following packages were automatically installed and are no longer required:
><snip snap>
>Use 'apt-get autoremove' to remove them.
>Done
>The following packages will be upgraded:
>  curl <snip snap>
>  <snip snap> libcurl3 libcurl3-gnutls <snip snap>
>  <snip snap>
>
>
>aptitude however doesn't,... it's not listed in the "Upgradable Packages"
>and when pressing "+" on the respective package (which does show both version)
>it doesn't select the correct candidate version (it does though when I press "+"
>directly on the version).
>
>
>Neither "Update package list", nor "Clean package cache" or "Clean obsolete files"
>resolves this situation.
>But at least this time (I haven't tried that before), "Cancel pending actions" plus
>restarting solved the issue, and the packages re-appeared for upgrade.
>
>So far (as said, I haven't tried the above before), the situation usually resolved
>by itself after a while (I susupect it did when really new Package lists came in
>from the repo).
>
>
>I think I have seen the whole issue even when packages where downgraded, but when
>I had already commented/disabled the "lower" repo (e.g. test) again.
>
>
>Last but not least, since this may be "used" to accidentally hide security upgrades,
>I selected important as severity. I'd guess a higher severity is not needed, since
>downgrades typically don't happen automatically, so the admin has at least a clue
>that he runs on an older version.

2015-06-12 12:41 ydirson at free.fr:
>Same here, it looks like only updating the package list again will bring those packages back into the "Upgradable" set.
>
>

2015-06-12 12:59 Axel Beckert:
>Hi,
>
>ydirson at free.fr wrote:
>> Same here, it looks like only updating the package list again will
>> bring those packages back into the "Upgradable" set.
>
>Explicitly marking the new version for upgrades also suffices,
>including future updates.

I am not sure why it is behaving in this, if it's an explicit
design/implementation decision or by chance, but I would not be
surprised if this behaviour is intentional and it's there from the
start, or comes after complaints along the lines of:

  "I want to keep this package downgraded and aptitude keeps nagging me
  to upgrade it all the time... please make it stop".

I have seen lots of bug reports with similar complaints, not about a
specific issue, but in the same sense "aptitude is not smart enough to
second-guess my perfectly sensible intentions or follow my commands
exactly, and I have a good reason to choose what I chose".  We even have
requests to let aptitude knowingly install broken systems:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721818

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795280

After all, if one *actively* downgrades a package version, while one
doesn't update the package list, aptitude is doing what was requested:
keep the version that was specifically selected (against the default
recommendation, that keeps being the same one until new become
available).  Maybe it's because that version is broken, or makes you
install 500GB of data that you don't want because of a mistake in the
packaging, so you know for sure that you don't want the newer version
until a new one fixing this becomes available.  And when a new version
becomes available, it lets you know so you can decide again.

The fact that it doesn't show in the set of Upgradable packages is also
consistent with this "don't nag me all of the time".  Picture this
user's rationale:

  "It is in the list of Upgradable all of the time, so after pressing U
  I still have to go to the N packages that I want to keep in the older
  versions and select the old version *one by one*, *every day* when I
  update testing / unstable / experimental.  *Annoying*".

In contrast, I cannot readily imagine a good reason to keep a downgraded
version if one is not happy with it, when one knows that there are new
versions available.  If after downgrading a package I still want the
newer one installed, even when the versions don't change, why wouldn't I
upgrade explicitly after I am done checking the old version?

apt is probably taking the simplest implementation and it doesn't
consider your previous preferences, just compares what it's available at
the moment.

So, in summary, I don't know if this is a bug or a feature (but I am
leaning towards the latter).  It will need more investigation / thought
in any case.

BTW, the fact that one has to actively select the downgraded version and
that when one updates the list the new version is offered again, is why
I downgraded the severity and removed the security tag.  If the security
fix is in the most recent versions and you explicitly downgraded it, it
is your decision; and if the security problem is in a yet-to-publish
version, it will offer the choice when the lists of available packages
are updated.  So I don't think that it increases the security risks in
meaningful ways.  Failing to update every day (or every few hours, even)
is probably a bigger security risk in many cases (openssl in exposed
services, or big holes in your browser).

Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>