purl field for distros

[noqcks]

What would you like to be added:

Just like syft generates a purl for packages, I would like to be able to generate purls for distros. The purl-spec supports a swid type that we can use for identifying OS versions.

One suggestion in the purl-spec was that an os type could be created, but the maintainers of purl-spec made it clear that swid should be used for identifying OS packages.

 "distro": {
  "name": "Fedora",
  "id": "fedora",
  "versionID": "29",
  ...
  "purl": "pkg:swid/Fedora@29?tag_id=org.fedoraproject.Fedora-29" 
 },

Why is this needed:

I would like to use a PURL for OS versions to identify OS versions that are End of Life for my project at https://github.com/noqcks/xeol

If the maintainers of Syft think that PURLs for distros is a fine suggestion, I can help implement it.

[wagoodman]

Interesting! I think this would be a fun addition.

I think the biggest question before starting on work is to understand how the tag id can be determined nicely for distros. That is, is there somewhere on the filesystem we could discover the tagid of org.fedoraproject.Fedora-<version>? or is this hard coded into syft? How many distros have known tag ids?

[noqcks]

Yeah, the big problem here is that I don't believe that many distros support swid tags atm

Supports SWID:

• Fedora

  $ docker run --rm -it fedora:29 cat  /etc/swid/swidtags.d/fedoraproject.org/org.fedoraproject.Fedora-29.swidtag
  
  <?xml version="1.0" encoding="utf-8"?>
  <SoftwareIdentity
    xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://standards.iso.org/iso/19770/-2/2015/schema.xsd http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd"
    xml:lang="en-US"
    tagId="org.fedoraproject.Fedora-29"
    tagVersion="1"
    name="Fedora"
    version="29"
    versionScheme="unknown"
    media="(OS:linux)">
    <Entity
      name="Fedora Project"
      regid="fedoraproject.org"
      role="tagCreator softwareCreator aggregator distributor licensor" />
    <Link
      rel="license"
      href="https://fedoraproject.org/wiki/Legal:Licenses/LicenseAgreement" />
    <Meta
      product="Fedora"
      colloquialVersion="29"
      summary="Linux distribution developed by the community-supported Fedora Project and sponsored by Red Hat, Inc."
      entitlementDataRequired="false"
      unspscCode="43233004"
      unspscVersion="20.0601" />
  </SoftwareIdentity>
  

• Redhat
  /usr/lib/swidtag/redhat.com/

No Support for SWID :

• Alpine
• Ubuntu
• Debian

As I understand, the distro creators should be creating SWID identifiers for their distros and storing that info at /etc/swid/swidtags.d (like they do in Fedora). https://github.com/swidtags/swid-linux-notes#finding-all-swid-tags. So we shouldn't be hardcoding in syft.

I just realized that cpes could also be used here to identify the OS version, and it looks like they are already supported in syft, but only for some distros. For example, amazonlinux has them, but not Ubuntu. Do you know why that might be? A bug or expected behaviour?

Amazon Linux

$ syft amazonlinux -o json | jq '.distro.cpeName'
"cpe:2.3:o:amazon:amazon_linux:2"

Ubuntu

$ syft ubuntu -o json | jq '.distro.cpeName'
null

[noqcks]

Upon further investigation, it looks like the CpeName is an optional property in /etc/os-release that distro creators can provide it as they wish.

CpeName runs into the same problem as SWID, where there is not a very high usage across the distros. (But more for CpeName than SWID).

Additionally, there's not really a way we could generate a swid purl for the OS based in the same way we do for package purls now without breaking the purl-spec, because tag_id is a required property on the purl and there's no way to intuit this without a SWID XML file.

[witchcraze]

At first ,I agree your comment.
// I wish OS EOL and extended support status are written in os-releases ...

And I think CPE can cover OS type (coreos, z_system) and exntended support status (eus) in some cases.
Checking with go-cpe-dictionary, there are ...

• cpe:/o:redhat:enterprise_linux:8.0::~~coreos~~~
• cpe:/o:redhat:enterprise_linux:8.3.0::~~advanced_virtualization~~~
• cpe:/o:redhat:enterprise_linux:8.5.0
• cpe:/o:redhat:enterprise_linux_eus:8.1
• cpe:/o:redhat:enterprise_linux_for_ibm_z_systems_eus:8.6
• cpe:/o:redhat:enterprise_linux:9.0
• cpe:/o:redhat:enterprise_linux_server:7.9::~~~~x64~
• cpe:/o:redhat:enterprise_linux_server:8.0

If syft (or other tool) can create proper CPE, we can clarify OS EOL perfectly.
But I think it will be dificult now.

In my work, I use current "distro" data to identify those OS EOL with internal mapping.
I could identify OS EOL of tens of thousands pod in our environment. So, this smple method was enoungh for me.

[bureado]

See package-url/purl-spec#214 and especially package-url/purl-spec#161 for extensive discussion over at purl including references to purl-CPE crosswalks.

In many cases, support status will likely be contingent on configured repositories and even access tokens/machine registration status beyond vendor/release tuples evaluated at a given time, notwithstanding the discovery/awareness value.

Also see SUPPORT_END over at https://github.com/systemd/systemd/releases/tag/v252

[spiffcs]

After reading this issue I think I'm on the side of adding this field as optional and filling it in when an operating system supports the SWID.

We can get an optional field added that adds the value for:

• Fedora
• Redhat

Opinion: I don't think we should start trying to compute the SWID if the distro does not support it yet.

I wanted to bubble @wagoodman's comment back up to the top since I think this is still an open question.

Do we have to determine this if the distro provides an SWID out of the box already?

Interesting! I think this would be a fun addition.

I think the biggest question before starting on work is to understand how the tag id can be determined nicely for distros. That is, is there somewhere on the filesystem we could discover the tagid of org.fedoraproject.Fedora-<version>? or is this hard coded into syft? How many distros have known tag ids?