Make reported tagId and version consistent for --package and --package-file.

[adelton]

@tobiasbrunner mentioned in https://github.com/strongswan/swidGenerator/pull/45#issuecomment-405969733 that @strongX509 might agree with this change -- could we have it merged?

[adelton]

Rebased on master, fixed tests -> 2af0fb93bcfe0cc3213c82ed2420d4e1b94e9494.

[tobiasbrunner]

As you are probably aware, this information is kinda redundant, as the OS name and version is the first part of the tagId (unless you pass an empty string via --os, but the format is not ideal then). So I guess an alternative to achieve consistency would be to remove -%{release} in get_package_list().

But I guess, since the package information is more accurate, another option would be to either replace the global os_string in tagId, if it can be derived from the package, or just omit it, if it's known the package version string includes it already. The same is probably true for the product attribute in the Meta tag.

What do you think?

[adelton]

We definitely do not want to remove the -%{release} part -- without it the information is really not usable at all, especially in distributions like RHEL and CentOS where the aim is to maintain API compatibility and old versions of software are maintained for many years and patches are backported. The -%{release} part is then the only thing which distinguishes httpd-2.4.6-17.el7 which was shipped with RHEL 7.0, and httpd-2.4.6-80.el7 which went out with RHEL 7.5.

While working on https://github.com/strongswan/swidGenerator/pull/47 and https://github.com/strongswan/swidGenerator/pull/48, I started to lean more and more towards thinking that the OS information is really irrelevant in SWID Tags for individual packages. I understand that it might be useful to have information that a particular package is part of some distribution but that should likely be achieved via separate SWID Tags linking the package and the top-level distribution Tag than encode the distribution information with the package.

On the other hand, your and your user's needs for the tool might be different, especially when you want to use swidGenerator as reporting tool with strongTNC. So I wonder if the command line options that allow catering to both needs might be the best way, for the tagId prefix and for the <Meta/> content.

[tobiasbrunner]

The -%{release} part is then the only thing which distinguishes httpd-2.4.6-17.el7 which was shipped with RHEL 7.0, and httpd-2.4.6-80.el7 which went out with RHEL 7.5.

Ah, the release part is the 17 and 80? Not the el7 or e.g. fc28 parts? If so, then that's not redundant and adding it definitely makes sense.

While working on #47 and #48, I started to lean more and more towards thinking that the OS information is really irrelevant in SWID Tags for individual packages.

Probably, but...

On the other hand, your and your user's needs for the tool might be different, especially when you want to use swidGenerator as reporting tool with strongTNC.

...that's the use case the tool was originally written for. So many of the design choices were probably driven by that (e.g. the absence of the architecture in the version string on dpkg platforms, or the Meta tag).

So I wonder if the command line options that allow catering to both needs might be the best way, for the tagId prefix and for the content.

Could be, we'd have to have a closer look at these.

[adelton]

The %{release} in rpm lingo is the whole part after the dash (sans the arch). It is typically configured to include %{?dist} so that different build environments can be distinguished. For example, the same .src.rpm when built in CentOS build system will be called httpd-2.4.6-80.el7.centos.x86_64.rpm and rpm will understand it that way:

$ rpm -qp --qf '%{release}\n' httpd-2.4.6-80.el7.centos.x86_64.rpm 
80.el7.centos

[tobiasbrunner]

Thanks for the explanation. I've merged this change to master.