[Aptitude-devel] Bug#768047: aptitude: doesn't inform a user that a package will no longer receive updates when it obsolete in the target suite, but not yet for an older suite

[Christoph Anton Mitterer]

tag 768047 + security
severity 768047 important
retitle 768047 aptitude: doesn't inform a user that a package will no longer receive updates when it obsolete in the target suite, but not yet for an older suite

Hi Axel.

I always wonder what the reason is for people to change other peoples
bug reports titles, tags, severity, etc., without any further
consultation of these people who probably didn't just choose them by
chance.
Sometimes it seems to be hiding away issues, arrogance (i.e. "I think I
know better, and change that now without further discussion") or perhaps
ignorance (i.e. not having checked closely enough or understood whether
something is a severe problem or not).

Don't get me wrong, I don't mean that I wouldn't make mistakes or my
opinion is higher than others,... but shouldn't it be usually require
some discussion what really applies or not, if just out of politeness?
Otherwise we could simply drop reporting any severity/tags completely,
since you'll always find someone who disagrees.

But since you seem to be neither member of the security team (and I
guess even that is probably not the ultimate group to decided where the
security tag applies to) or maintainer of aptitude (or did I miss
something),... I don't see why your arguments that this is a non-issue
should be stronger than mine that it is.
Therefore reverting severity and tags.


As for the title:
It took me a while to understand what your new suggestion actually
means, and I think it's a bad title, cause it implies that a feature is
wanted that shows (and therefore in the end also installs) packages from
anther suite, even if those packages where deselected via explicit
apt_preferences policy configuration.
Clearly not what the user wants, and clearly not what aptitude should do
with any feature.
Just because e.g. lcms1 is no longer upgraded in unstable, this should
mean that aptitude proposes it to downgrade to a "new" older version,
when a security update comes out.
What is really wanted is, as I've tried to describe before, a feature
that shows people for which they no longer get updates.

I did though give another title, than my original, which should make
more clear now what is missing.


> ... which is correct because it isn't obsolete as it's still
> downloadable.
> 
> Please see the documentation how the "obsolete" filter and grouping
> is defined in aptitude:
> 
> "This term matches any installed package which is not available in any
> version from any archive. These packages appear as “Obsolete or
> Locally Installed” in the visual interface."
Well I've seen that, but this probably simply isn't perfectly defined in
the light of having multiple suites with different statuses of the same
package.

The category isn't *just* "locally installed packages" it's "obsolete
*and* locally installed packages".
When having only one suite, and a package is dropped from that (which
implicitly means "user, you won't get any further updates"), than things
obviously match that definition, as you say.

But as soon as you have multiple suites enabled (for the same repo), or
especially when you also have things like snapshot.d.o enabled, that
definition of "obsolete" makes no longer much sense, since one likely
always finds a suite where one can download a package from.

For the user, who has such a package already installed, the information
"you cannot donwload this anymore" is rather useless anyway, why should
the user want to download it again, he already has it installed.
The information that is of interest in the end is: "this package is no
longer part of the repo and will no longer be updated".

Now in the multi-suite scenario I've described it *is* of course still
part of some repo, but not of the user's "main" repo.


> > which of course also means that I wont't get any further (security)
> > upgrades for it in unstable and of course I won't get upgrade to
> > stable as well, since lcms1 isn't what I'm selecting via
> > apt-preferences.
> 
> This is IMHO in the user's responsibility if he decides to mix stable
> and unstable.
Well that basically ends up in the same discussion and questions that
were already asked here #752450 (respectively in some parts on d-d,
where some people removed the bug from being CCed):
IMHO (and some other people agreed), there should be a systematic way of
informing people about updates and especially also when a package runs
out of support.
Systematic way in the sense, that apt/aptitude tell you, and not that
the user has to manually collect that information from all kinds of
places (not to talk here about the security implications which this in
turn has, and which is more thoroughly discussed in the aforementioned
bug.

The situation I've described here however, i.e. unstable/stable mix,
there is now real obvious way for a user to check that. DSAs would be
only issued for stable/testing,... any one probably cannot demand users
to regularly read: http://ftp-master.debian.org/removals.txt

You also cannot just say it's "user's responsibility if he decides to
mix stable and unstable", because this would basically limit one to only
mix oldstable/stable/testing with each other, and to not mix in any
other repo at all. Cause the same issue obviously applies when I take
e.g. ffmpeg from DMO and if that would remain there supported on a lower
version, while I have the Debian ffmpeg on a much newer major version
(in the case it would be dropped from unstable).


> Actually aptitude already offers you the tools to find such packages.
> Just build the according view filter, e.g. call:
> 
> aptitude -o "Aptitude::Pkg-Display-Limit=~i ?any-version(~Osecurity) !~U !~o"
Just tried that on the lcms1 example (having installed it from testing
since it's gone from unstable, but completely disabled the testing repo
again afterwards - should be the same situation as if it would have been
just dropped from unstable), so back to the situation:
A version is installed that is no longer in the target suite for that
very package (unstable), but still available in some other suite
(stable).
That invocation doesn't show any package at all in aptitude.


> It's untested as I don't seem have any package in such a state, but
> based on what I use to emulate apt-show-version's "newer than in
> archive" with aptitude:
> 
> aptitude -o "Aptitude::Pkg-Display-Limit=~i ?any-version(!~O.) !~U !~o"
same as above, nothing is shown at all.


> Downgrading to wishlist as this is clearly a feature request and not a
> bug -- it works as designed. Also removing the tag security as
> security updates for unstable are official not available, as you
> already mentioned, hence your scenario is not officially supported
> either.
Well as I laid out before if it's designed like that than it's
nevertheless a bug, i.e. the missing way of telling a user per default
that he won't get further updates..

And for the security tag:
That seems to be defined as:
"This bug describes a security problem in a package (e.g., bad
permissions allowing access to data that shouldn't be accessible; buffer
overruns allowing people to control a system in ways they shouldn't be
able to; denial of service attacks that should be fixed, etc). Most
security bugs should also be set at critical or grave severity."

which just perfectly applies, the current way of handling things, allows
a package to get into a state where it's no longer update, without
anyone ever noticing it.
The definition doesn't tell, that it would only apply to security
supported suites.

That being said,... we can probably argue about the severity, whether it
is wishlist or not. But I don't think we can about the security-tag.
And IMHO, one of they key duties of apt/aptitude is package management
inculding keeping the system up-to-date,... and if the current design
doesn't fulfil this, even if just in some corner-cases, it's at least
more than just a wishlist.

I mean if gnupg would tell you that any signature is okay, even if just
in some cornercases, you'd probably still consider it an important
security bug, if not rather a critical one.


Cheers,
Chris.