I am being encouraged to NOT file an issue with a question on github, so… Here's a weird, basic-feeling blind spot: Ubuntu does not have a 'patch' field in its os-release output, and so osquery initializes integer 0 and that becomes the value. The patch level is present in the full, all-caps "VERSION" string output with a whole bunch of info, (e.g. "20.04.4 LTS (Focal Fossa)") but the os_version table doesn't bend over backwards attempting to parse it out of there. Should I file a feature request to fix it?

I don’t think I know enough Ubuntu to have any sense. @alessandrogario @Stefano Bonicatti Either of you have an opinion here?

I've asked people in my company that are on the canonical steering committee whatever thing to chime in on the topic and they don't seem quite convinced at first glance that they should make parsed output for patch level

patch version doesn't really apply to Ubuntu as much as it does for RHEL

a fully up to date 20.04 should have almost identical packages as a 20.04.1 install

my qualm with it being unavailable is that the media used to install the OS is valuable info to tell the history of interactions with the computer for my team/role, and if it's valuable enough to update the version/description string with, I don't know why that can't additionally be presented in a trivially parse-able format

If only LSB was a real standard and the distro used a single format.. In any case, I don’t have strong opinions beyond the fact that if the distro does not consider that format as somewhat fixed, it could break the parsing.

I'm not for or against parsing the string, but considering they haven't changed it in even 22 LTS means this would cover a whole bunch of devices in use and potentially could remain stable enough

But re-reading, you’re right for the default to 0. We should either return empty or attempt to parse it.

yep, had encountered this before:

Nothing in the definition of /etc/os-release requires that this field be updated for point releases. It is Ubuntu policy to not update the machine-readable field in this file (and in /etc/lsb-release), because software *should not* treat point releases differently than they treat the original release. If there is a need to treat the releases differently, it should be on the basis of specific packages that are installed (or not), which you would check with dpkg, not with /etc/os-release.

https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1394469

Great, so being obstinate about it is Policy 😬

@allister If one installs a

20.04

machine with the .1 media. I assume the release is

20.04.1

right? If time passes, and there is then a

20.04.2

, does my

20.04.1

machine update that when it’s fully taken updates, or is it a weird artifact of the installer?

I’m still going to maintain the impression (however unfounded, I’m not a Debian expert nor is Ubuntu my daily driver) that ‘media’ used for both initial install and ‘landmark’ updates has non-zero value, but if they want to purposely avoid writing this out for their platform, mazel tov

“maybe” As I said, I think it could be interesting to gather. But I would not attach it to the OS version string. Fundamental in these are that the OS version is upgradeable. Neither macOS nor windows provides an immutable way to see what the original installed version is.

until Apple's planned Rapid Security Response things land, it's still the case that webkit and firmware and countless other things regularly depend on OS patch levels. That being said, Apple doesn't make it machine-parseable by default neither, so it's all chopping strings

I think we’re talking cross purposes.

there's no patch field whatsoever in os-release output is the current/previous state for ubuntu

On a fully updated ubuntu machine, does the value change? Earlier you said not.

ubuntu machines have the full version in the VERSION output of os-release, AFAICT it stays in sync with base-files