Security updates are not marked as security

[xor]

I have two machines, both on Kubuntu 14.04 amd64, one on the German package server, one on the central one.
/etc/apt/sources.list for German server attached, for English server will follow in a comment because I can only attach one to the initial report
/etc/apt/sources.list.d is empty

Both have the same version of openjdk-7-jre installed according to aptitude (7u65-2.5.1-4ubuntu1~0.14.04.2).
Both show an update to 7u65-2.5.2-3~14.04 in aptitude.
However, the one with the German server shows it as security update according to aptitude, while the central server shows it as regular update. The package list was updated on both in the same interval of a few seconds.
Why?
[Notice that this might affect other packages, I am seeing more differing updates, only bothering to check the versions for this one.]

Notice that this was preceded by weeks of aptitude telling me about bad signature / bad checksum when updating the package list (which made me switch the server to central server on one machine), and your recent update of apt which seemed to fix security issues in apt according to the changelog. This is very suspicious to me. Are you hacked? Am I being hacked? I work on a high value target software (Internet anonymization), so this scares me.

Please reply soon if you need further information about the state of my apt, I can only postpone the security updates for a short time, and afterwards the state of apt might have changed in a way which makes it impossible to debug.

[xor (xor)]

# Machine with German package servers
$ apt-cache policy openjdk-7-jre
openjdk-7-jre:
  Installed: 7u65-2.5.1-4ubuntu1~0.14.04.2
  Candidate: 7u65-2.5.2-3~14.04
  Version table:
     7u65-2.5.2-3~14.04 0
        500 http://de.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
 *** 7u65-2.5.1-4ubuntu1~0.14.04.2 0
        100 /var/lib/dpkg/status
     7u51-2.4.6-1ubuntu4 0
        500 http://de.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

# Machine with central package servers
$ apt-cache policy openjdk-7-jre
openjdk-7-jre:
  Installed: 7u65-2.5.1-4ubuntu1~0.14.04.2
  Candidate: 7u65-2.5.2-3~14.04
  Version table:
     7u65-2.5.2-3~14.04 0
        500 http://archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
 *** 7u65-2.5.1-4ubuntu1~0.14.04.2 0
        100 /var/lib/dpkg/status
     7u51-2.4.6-1ubuntu4 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

[Seth Arnold (seth-arnold)]

Thanks for your concern; this is standard and expected behaviour. The security.ubuntu.com server farm is fairly small and on limited bandwidth compared to the wider Ubuntu mirror network so our security updates are periodically copied into the -updates pocket for wider distribution and mirroring.

This allows the majority of people with daily checks to mostly get their updates from the mirror network, saving bandwidth for security.ubuntu.com and providing them with faster downloads but still allows for people to get security updates as quickly as we publish them, if desired.

Depending upon when your machines request package list updates from the mirror network, and which mirrors you contact, and where in that individual mirror's copies you land, you may get a security update via the -updates pocket or the -security pocket.

Some additional background on this can be found at https://wiki.ubuntu.com/SecurityTeam/FAQ#Repositories

Good paranoia, but this part is acting as normal. :)

Thanks

[xor (xor)]

Thanks but I don't quite understand what you're trying to say.
There are two interpretations of what you said:

1) Did you misread my report and thought I was complaining that one machine does not see a security update yet while the other sees it? That is NOT the case. They both see the same package update, that is an update which claims to be the *same version number*. But on one machine the version is marked as *security*, and on the other it is NOT marked as security.

2) Or are are you telling me that updates which *are* security updates are *normal* to be NOT marked as security updates for some people? That is very very bad. If something is a security update, it needs to be marked as such, otherwise people won't install it quickly!

[Seth Arnold (seth-arnold)]

It is normal for security updates to be copied to the -updates pocket of the mirror network in order to provide better update availability and speed to everyone.

We don't expect users to determine if an update is a security update based on the URL where the package can be found.

Instead, our updater will by-default prompt users to install security updates daily (see System Settings | Software & Updates | Updates -> "When there are security updates").

We also publish Ubuntu Security Notices for officially supported packages -- http://www.ubuntu.com/usn/ and https://lists.ubuntu.com/archives/ubuntu-security-announce/ -- for users who want to stay on top of security updates manually.

Administrators may also install the unattended-upgrades package if they want to install security updates (or other updates) automatically.

Thanks

[xor (xor)]

Thanks.
It has been 2 days now, and the package is still showed as NON-security on the machine even though I have updated the package list just now.
No matter what possible technical explanations are, from a system administrator's perspective, it is a bug if a security update is marked as non-security for over 2 days.
Thus, please re-open the issue. Also, please be so kind to fix this soon: I have taken the machine out of production just so I can help you with fixing the issue. I *need* the machine for work, so it would be nice if this situation could be resolved soon.

(Also, please notice that even the idea you described of spreading the packages as non-security just for a few hours might be bogus: Admins use tools such as apticron to get notified by mail about package updates. While I have not verified that, it seems probable that those tools will just check the version and not send out another mail for the same version. So when you get the first mail about it NOT being a security update, another one will likely not be sent once it changes to security. Then the administrator will not install the update any soon because he thinks it's not security relevant.)

[Seth Arnold (seth-arnold)]

You will only see a security update in -security in the first few hours after publication; depending upon a large number of variables it might be visible in a mirror's -updates pocket within minutes or maybe a day later. This is a one-way transition -- there's no point in checking again once the package has been copied to the mirror network. You'd have to be scanning for updated packages every half hour or so to try to catch a package in only the -security pocket.

Please do not use the URL to determine if a package is a security update.

If all you want is security updates you can remove the -updates pocket from your repository configurations but be aware that a great many reliability fixes are made available only in -updates.

Thanks.

[xor (xor)]

Ok I think I finally know where we are misunderstanding each other: I am *NOT* using the URL to determine whether it is a security update!

I am talking about the fact that the user interface of aptitude has a category "Security updates" and "Upgradable packages". The package is displayed at "Upgradable packages" instead of "Security updates". The KDE "Muon" thing also does not show anything about security updates.

So the mechanism of apt which detects that it is a security update is broken. Whether it uses the URL for that or whatever else is not at my knowledge.
I only know that a package which is a security update is not marked as such in the user interface, and that is definite breakage.

Can you re-open this now? :)

[Seth Arnold (seth-arnold)]

Ah! That's the missing piece indeed. I've never used aptitude or muon so I've never noticed the discrepancy.

Thanks

[xor (xor)]

Thanks.
Muon is the default package manager and "there's an update" tray icon alert thing in Kubuntu, so you might want to judge the priority which is not set yet upon that.

FYI the issue still applies, today is day 3, so I would assume it really is not a package server synchronization issue.

[Ｖ字龍(Vdragon) (vdragon)]

@xor
Hi, my theory is "it's probably not possible for the apt and its front-ends to determine which update was security update after the update has been moved to -updates channel(until the developers decided to change the 'move-to-updates' policy)", I suggest you to upgrade all packages no matter it is from -updates channel or -security channel to keep your system safe, for my system I setup upgrade all packages from all channels(except -proposed) automatically in background using the unattended-upgrade mechanism and currently, hasn't encountered any problem.

[Rolf Leggewie (r0lf)]

I would look into pinning, can this possibly help here?

[Axel Beckert (xtaran)]

Hi,

Rolf Leggewie wrote:
> I would look into pinning, can this possibly help here?

No, this has nothing to do with pinning at all.

This is a known issue with aptitude. Have a look at the function
is_security() in src/generic/apt/apt.cc: aptitude only regards as
security update if the repository is from security.debian.org or
security.*.debian.org, at least in Debian.

So I assume that Ubuntu patches those lines towards
security.ubuntu.com as used in his German sources.list.

But his "central" sources.list doesn't have security.ubuntu.com
anywhere. He uses e.g. "deb http://archive.ubuntu.com/ubuntu
trusty-security main restricted" there. And hence it's not recognised.

I thought there was an upstream (Debian) bug report about that (as I
am aware of the issue :-), but I couldn't find it on a first glance.

Will file one and link it here.

  Regards, Axel (with his aptitude hat on)
--
 ,''`. | Axel Beckert <email address hidden>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
  `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE