highlight security updates

[frisi]

it would be great to add a C flag on host and package level that indicates critical security updates.

this might be solved with #13. nevertheless i created a separate issue since this feature might be easier to implement and add to a new release.

[liske]

You're right, it requires an extension of the apt-dater-host protocol as #13 does, too. Thanks for pointing out that special use case on top of #13.

[mc0e]

+1. This would be hugely useful to me. I'm responsible for enacting a conservative policy where updates are applied only for security.

Apart from just displaying which are security updates with a flag, I'd like to be able to tell apt-dater to update a host only to the extent necessary for security. i.e. much the same as if I use the aptitude curses interface, and hit 'g' on the security updates section. It'd also be useful to have a set of hosts listed under 'Security Updates Pending', much like the 'Updates Pending' section that's there now.

[tpo]

The following patches/pull requests implement differentiating/displaying of security updates:
#148
DE-IBH/apt-dater-host#25

[tpo]

There's a problem with all of this:

When you run apt-get --simulate dist-upgrade or aptitude --simulate dist-upgrade (which is what apt-dater-host does), then that will not dependably show you which of the pending updates are security updates.

If you have a packgage "application" and Ubuntu does a security update say for "trusty" of that package, then that package will both show up in the "trusty-updates" and in "trusty-security".

This is visible in apt-cache policy application. Both repositories have the same priority. However apt-get --simulate upgrade (just like aptitude) will tell us that they would "Inst" the package from "trusty-updates".

So "trusty-security" as a repository will not show up in the output of apt-get and so apt-dater-hostwill not get to know, that indeed there is a security update pending!

I have not found out how to tell apt-get to prefer "trusty-security".

The check_apt plugin for the nagios family of monitoring systems has exactly the same problem.

But we can develop this idea further. What if "trusty-updates" has a newer version (say V1.0.2) than "trusty-security" (say V1.0.1secfix) (which happens if Ubuntu (or maybe more often Debian) releases minor updates to packages)? Then even if you somehow managed to tell apt-dater to prefer "trusty-security" over "trusty-updates", the version from "trusty-updates" will win, because of the higher version number and you will not know, that there's a security update pending.

Even if apt-dater(-host) would be able to find out that there's both an update and a security-update pending, then how should the user be notified about that in the user interface? Two entries for the same package? Multiple version numbers? What would happen if you press 'i' or 'u' in apt-dater? To which version should that package then be updated? Note that one can push this line of thought further, since apt allows an "infinite" number of repositories to be used, each with its own version of a package.

So what are the solutions? One would be to see how aptitude does it when in "curses" mode, because it has a "Security" section that contains security updates.

Another way further would be to have a look at the unattended-upgrades package, that does the same thing, however it explicitly needs to be configured and told which repositories are eligible for upgrades.

In conclusion, I think including this feature has its value and merits inclusion. The problem is however that it yields false negatives (there's a security upgrade pending, but apt-dater won't tell you).

Does anybody have any idea on how to go forward from here?

[mc0e]

Aptitude checks whether the update is available on security.debian.com, or security.ubuntu.com depending on your OS variant. It looks like it would be ok if the version was available in other locations also.

From pkg_grouppolicy.cc in Ubuntu code:

// 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.ubuntu.com")
      return true;

  return false;
}

It's not necessary to know that the security update is the latest, (or indeed to update to the latest). We only need to know that a version is available from the security repository which is more recent than the installed version.

The output of e.g. aptitude versions --disable-columns linux-tools-generic is interesting for looking at available versions for a specific package. It seems that something like apt-cache should be able to give that info also, but I'm not sure how.

[tpo]

Hmm. So I have searched further around. My reasoning at this point is:

• in order to know what will or will not be updated, we do want to use the resolver that either apt-get or aptitude provide (is there an alternative to this?)
  -> 1. we could use the aptitude pattern matching interface [1] and a custom output format [2]
  -> 2. or we could use libapt /libapt-perl

Strategy 1:
It looks like aptitude's search is either broken, or I do not get how to use it:

$ aptitude -F "%p %v %V %O %t" search "?exact-name(util-linux)"
util-linux                                                 2.29.2-1       2.29.2-1+deb9u Debian-Security:9/stable [amd6 stable                                
util-linux:i386                                            <keine>        2.29.2-1+deb9u Debian-Security:9/stable [i386 stable

which looks useful (why does it list util-linux:i386?!), however searching for the exact same thing, restricted to the Debian-Security origin:

$ aptitude -F "%p %v %V %O %t" search "?exact-name(util-linux)?origin(Debian-Security)"

yields nothing. What is wrong here?

However, either way, what we'd need in reality is to be able to do "?section(Security Updates)" but it looks like that's not available. Or we could do the same as aptitude does - match the site, where it'd download the package from, but unfortunately that field doesn't seem to be available in the output formatters [2].

Strategy 2:
I have been looking at the libapt interface (apt-get install libapt-pkg-doc) for a while but haven't found anything useful yet. ?

I can't see how to go about this at the moment. Maybe go and fix aptitude (which seems to be semi-maintained (?)) first?

[1] https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html
[2] https://www.debian.org/doc/manuals/aptitude/ch02s05s01.en.html

[tpo]

There is a patch (see https://bugs.debian.org/892983) for aptitude to allow filtering for package release "Label" (in this case "Debian-Security") and a request to be able to filter for package release "Suite" (in this case "xenial-security") (see https://bugs.debian.org/892984).

Also it is possible to do this filtering in apt-get like follows.

On Debian:

# apt-get upgrade -t "l=Debian-Security" util-linux
Reading package lists... Done
Building dependency tree   
Reading state information... Done
util-linux is already the newest version (2.29.2-1+deb9u1).
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

On Ubuntu:

# apt-get upgrade -t "s=trusty-security" isc-dhcp-client
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
isc-dhcp-client is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

So it should be possible to integrate my patch here: #24 (comment) with the above suggested apt-get parameters to be able to see security updates.

There is the request #13 to be able to add sections in apt-dater for different views on the packages, among other pending security updates. I think I will not be looking into that, at least not now (not least because I can't much wrap my head around it how that should work/look like in the UI). If anybody wants to proceed in that direction, then please do. It'd be cool to provide some feedback.

@liske - any thought on all this?

[tpo]

there are comments from @liske in the pull request here: DE-IBH/apt-dater-host#25

[tpo]

A new implementation, following along @liske's design suggestion is available here DE-IBH/apt-dater-host#25 (comment)

[wwuck]

I'm testing out apt-dater on Devuan and just wanted to add a comment about the Devuan apt sources. This is an example sources.list from one of my machines:

deb http://deb.devuan.org/merged/ ascii main contrib non-free
deb-src http://deb.devuan.org/merged/ ascii main contrib non-free

# ascii-security
deb http://deb.devuan.org/merged/ ascii-security main contrib non-free
deb-src http://deb.devuan.org/merged/ ascii-security main contrib non-free

# ascii-updates
deb http://deb.devuan.org/merged/ ascii-updates main contrib non-free
deb-src http://deb.devuan.org/merged/ ascii-updates main contrib non-free

Hopefully your proposed changes will work out-of-the-box with Devuan 👍

Further information on Devuan APT sources:
https://devuan.org/os/
https://devuan.org/os/etc/apt/sources.list