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

[Christoph Anton Mitterer]

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.


> 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.



> 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).


> 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...

> In a deeper sense, the package is dead upstream, thus not maintained,
> thus obsolete and a potential security liability, and that's the
> reason
> why it was removed from Debian.
But the problem will happen with any other package, whether it's
maintained or not,...


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.

Since this has nothing to with DMO, reopening.

Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20160806/b28403ca/attachment.bin>