[Aptitude-devel] Bug#833482: Bug#833482: aptitude: doesn't detect obsolete candidate package (versions)

Sat Aug 6 00:12:34 UTC 2016

Control: tags -1 - security
Control: close -1

2016-08-05 23:06 GMT+01:00 Christoph Anton Mitterer <calestyo at scientia.net>:
> Control: reopen -1
> Control: tags -1 + security
>
> On Fri, 2016-08-05 at 22:49 +0100, Manuel A. Fernandez Montecelo wrote:
>> This effect is an interference caused by the repositories that you
>> use.
>> Debian doesn't sanction the use of any unofficial repositories, and
>> DMO
>> is well known in the community for causing all sorts of problems when
>> using along with the main Debian repositories, such as this one.
>
> So? The underlying problem exists whether or not DMO is well
> maintained.
> If any non-Debian repo is configured that uses the same package names
> (and I don't think that Debian claims namespace authority of all names)
> than it wouldn't be detected if the candidate versions are obsolete.

The underlying problem is that you think that using Debian + external
repositories which don't play well with Debian is a supported
scenario.

From: http://www.debian.org/doc/manuals/debian-faq/ch-choosing.en.html

"In most situations if you stick with one distribution you should use
that and not mix packages from other distributions. Many common
breakages arise due to people running a distribution and trying to
install Debian packages from other distributions. The fact that they
use the same formatting and name (.deb) does not make them inmediately
compatible."

(there are similar warnings about mixing different Debian
distributions/suites except in completely compatible overlays, e.g.
"security")

Using repos which cause namespace clashes and the "overlay" doesn't
have the "base" into account is prone to this kind of situation.  It
also happens with backports sometimes (see below).

If DMO had transcode as a well supported package (perhaps packaging a
maintained fork while keeping the same name, for example), it wouldn't
be a security problem at all, you could switch to it instead.  From
aptitude's POV, it's not "obsolete", because it's present in other
repo.  It doesn't even know where it came from, you could have
installed that package/version locally with dpkg.

The fact that it was removed from unstable is not an indication that
it's a security problem either.  It's only "obsolete" or a "security
problem" from your POV, because you know extra information that
aptitude cannot know.

The only solution for this particular problem is DMO stopping to ship
this package, if it indeed has security problems; and for this and the
more general problem of packages dropping from repositories while
present in others is you to monitor such packages, with the tools that
aptitude gives to you (and Obsolete is the wrong tool in this case).

It's not a security problem related to Debian or aptitude in any case,
and neither aptitude maintainers or the security team will be able to
do anything about this, so it's not actionable as a security issue.

>> If the example was with another repository which is well maintained
>> and
>> co-operative, e.g. "mozilla.debian.net" containing a package
>> "iceweasel"
>> for compatibility (which was removed from Debian), the package
>> shouldn't
>> be considered obsolete.
>
> The problem happens with these as well:
> Consider I have had transcode installed from sid (where it's been gone
> in the meantime) and also enabled stable (where it's still in), I'd
> expect the same as I've seen it with DMO.

Mixing stable and unstable is not supported either, precisely because
it leads to this kind of problem.

>> Obsolete from aptitude is "installed locally but not found in any
>> repo",
>> which works well for the main intended uses of aptitude.
> Well and that's the problem here, the definition of obsolete is kinda
> wrong.
> Or perhaps not wrong, but it doesn't tell you when a package no longer
> will get updates (which is however the interesting thing about
> obsolete/non-obsolete).

We already discussed this in previous bugs.

aptitude, as many other Debian tools, is designed with the main idea
in mind that users will have supported versions, e.g. only stable,
unstable, and so on.  In these cases, "obsoletes" works well and
always as expected.

Anything else, you're on your own.

>> So it's not an important bug, and aptitude is not the cause of the
>> security issue -- using DMO is.
> I don't think DMO has anything to do with...

Well, yes, to be fair DMO hasn't anything to do with it... again, the
actual problem is that you think that you can use both unstable and
DMO and report bugs as if it was a supported scenario ;)

> The "bug" or let's call it "deficiency" or "missing feature" in
> aptitude is:
> It doesn't show when packages will no longer get updates via the
> configured repos and as per configured apt_preferences.
>
> This is however quite important, as it also happens when just mixing
> Debian repos.
> Take backports... if one adds jessie-backports, and e.g. installs
> icinga2 from there, perhaps pinned via apt_preferences(8).
> It's still contained in jessie (at a much lower version), if it would
> now be removed from backports, because lack of manpower or whatever,
> users wouldn't notice that their installed version is obsolete in the
> sense that it won't get any further security updates.

https://backports.debian.org/FAQ/

Q: Is there security support for packages from backports.debian.org?

"A: Unfortunately not. This is done on a best effort basis by the
people who track the package, usually the ones who originally did
upload the package into backports. When security related bugs are
fixed in Debian unstable the backporter is permitted to upload the
package from directly there instead of having to wait until the fix
hits testing. You can see the open issues for wheezy-backports in the
security tracker (though there may be false positives too, the version
compare isn't perfect yet)"

So, basically, mixing repos is not supported because it leads to this
kind of problems, not even backports is 100% safe.

It's quite well known in the community, really.

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