[Aptitude-devel] updates in aptitude appearing in "Upgradable packages" rather than "Security Updates"

[Axel Beckert]

Control: retitle -1 Status grouppolicy miscategorizes security updates by only looking at the hostname, not at the Release file (e.g. via apt-proxy)
Control: found -1 0.6.11-1

Hi,

Raphael Hertzog wrote:
> On Fri, 17 Oct 2014, Cedric Knight wrote:
> > For wheezy, security updates appear the "Security Updates" section of
> > the main view of the aptitude package manager.  However, on servers
> > using "deb http://ftp.uk.debian.org/debian/ squeeze-lts main contrib",
> > security updates are not distinguished from other "Upgradable
> > Packages", which is a bit confusing.
> > 
> > Is there any way to get them listed under "Security Updates"?

No.

> I don't know exactly what criteria aptitude is using to sort those
> updates so I can't really tell you. I'm putting the aptitude developers
> in copy so that they can reply.

Thanks.

Aptitude uses what "apt-cache policy" shows (well, not literally).
From "apt-cache policy"'s output:

Debian Squeeze Security:

 500 http://security.debian.org/ squeeze/updates/main i386 Packages
     release v=6.0,o=Debian,a=oldstable,n=squeeze,l=Debian-Security,c=main
     origin security.debian.org

Debian Squeeze LTS:

 500 http://debian.ethz.ch/debian/ squeeze-lts/main i386 Packages
     release v=6.0-lts,o=Debian,a=squeeze-lts,n=squeeze-lts,l=Debian,c=main
     origin debian.ethz.ch

aptitude looks for the string "security.debian.org" in there and it
isn't anywhere in the LTS Release file.

The according code is in src/pkg_grouppolicy.cc:

// Stolen from apt-watch:

/** Tests whether a particular version is security-related.
 *
 *  \return \b true iff the given package version comes from security.d.o
 */
static bool version_is_security(const pkgCache::VerIterator &ver)
{
  for(pkgCache::VerFileIterator F=ver.FileList(); !F.end(); ++F)
    if(string(F.File().Site())=="security.debian.org")
      return true;

  return false;
}

> Depending on how it's implemented, it might be doable by adjusting the
> contents of the squeeze-lts Release file. Otherwise it might need a fix
> in the aptitude codebase.

So it's the latter as "security.debian.org" is hardcoded _and_ it's
the origin which seems the hostname from the sources.list (i.e. it
will break anyways if you use a non-official security mirror like e.g.
the one at http://mirror.hetzner.de/debian/security -- Especially
modifying the Release file itself won't help at all.

I was about to document this in a bug report, but there is actually
already one: https://bugs.debian.org/328620 -- Cc'ing it. It should be
updated accordingly with this mail.

But then again -- should we really declare Squeeze LTS updates as
security updates? I don't think so. They were announced as not being
equivalent, the "S" in "DLA" is missing, there's no more distinction
between security- and non-security-updates (AFAIK), etc.

I also don't recommend to not change the current setup significantly
during the squeeze-lts cycle to not mess with people's already
established setups. It's merely something which we should think about
for wheezy-lts to make it better there.

> We have a similar problem with unattended-upgrades which will not detect
> those updates as security updates because the repository label doesn't
> contain the word security IIRC. Michael, is that something that you wish to
> fix with a squeeze-lts upload? Or is that something that we should fix
> by updating the squeeze-lts release file? (Ccing ftpmasters so that all
> involved parties can voice their opinion)

I don't think that's needed anymore either -- currently there is no
more distiguishing between security updates and (old)stable minor
updates. So either apply them all automatically or none.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20141021/c47fa3c1/attachment-0001.sig>