adding enumeration to the namespace field; adding enums for deb/rpm

[jacobcalvert]

PR Changes

adding the ability to have an enumeration given to specify valid values in the namespace field

This adds a valid_values optional key to the namespace_definition schema so that we can restrict the namespace field to a valid set of value

adding those values to RPM and DEB types

I have added these specific enum values to the DEB and RPM types.

For Discussion

Non-descriptive Namespaces

It appears that some SBOM generators read the ID field from /etc/os-release which can work well sometimes (e.g., for Ubuntu it reports ubuntu) but in other cases it is nonsensically short (e.g., OracleLinux reports ol). In these cases I just opted to specify the namespace by following the convention of the others in its category, so Oracle Linux became oraclelinux following the form of almalinux and others.

Edit:

I have run:

make check
make formatjson
make gendoc

And it seems make gendocs reformatted the CPAN markdown. I don't know why. I can revert that change if needed.

[pombredanne]

This is a follow up from

• adding enumerated namespaces for the most popular vendors for rpm and deb types #370
• @giterlizzi @gernot-h @hroncok @meljw you had commented on it

[pombredanne]

MUST is a problem as I cannot enumerate ALL the known RPM-based distros at all times, so SHOULD would be better. We can also ensure in validation tests that we can return a warning as this would round up the thing nicely.

[gernot-h]

Another aspect to consider here are custom packages you add to an OS image/installation, say you build and install your own, patched version of the kernel. In my eyes, an ideal SBOM scanner should detect that the vendor for this package is not debian/opensuse/... and set the namespace accordingly to gernot-patched or unknown. Not sure if this should explicitly be mentioned in the spec or we simply leave it at SHOULD which would allow this degree of freedom?

[pombredanne]

Since we cannot really be exclusive, I would rather could this "known_values"

[matt-phylum]

I think we need a set of known values rather than a set of valid values. If implementations are validating that they are receiving only the expected values then adding new values (eg adding Linux Mint) is a breaking change.

[mjherzog]

This PR is our first proposed change to the purl-types-definition.schema.json after freezing it for submission as part of the Ecma standard. At a minimum we need to save a copy of the current purl-types-definition.schema.json file as purl-types-definition.schema-1.0.json before accepting any changes.

I have created

• Freeze purl-type schemas for Ecma standard #679 for purl-types-definition.schema.json and purl-types-index.schema.json.

Beyond that detail task I think that we need to talk a more formal process for any changes to purl-types-definition.schema.json (other than fixing typos, formatting or similar). My immediate suggestion is that schema changes should be approved at a TC54-TG2 meeting. This particular change seems like a good idea to me, but we need a more deliberate process for schema changes as a step toward more mature project governance.

[jacobcalvert]

@pombredanne and @mjherzog anything else I need to do for this PR or is it just process/approval stuff now ?

[mjherzog]

@jacobcalvert We discussed this PR during the PURL community call this morning and there are some relevant updates from the call:

• The group affirmed that we need a more formal RFC-type process for changes to the purl-definition-type.json-v1.0-schema because it has been submitted for Ecma standardization.
• There is some concern about what this means for other types like npm where there are hundreds of "known" namespaces which are not practical to list. The apparent answer is to avoid using this property for those cases.
• There needs to be consideration of what this change would mean for tests. If a PURL is otherwise valid but has an unregistered namespace does that validation test result in an error, warning or info message.

I apologize for stacking up so many issues on top of this PR, but thank you for being the catalyst for raising them. This will be a topic for further discussion at the next PURL community meeting on October 1 (https://meet.google.com/ryq-aimn-ghd).

[mjherzog]

@jacobcalvert
I have created Issue #690 as a more formal schema change proposal with the goal of raising it for discussion/approval at the next TC54/TG2 meeting on October 10 (see https://tc54.org/purl/ for access info).
In the meantime I suggest 3 changes to the PR:

• Please replace "known" with "registered" because known is extremely ambiguous. Registered means that the namespace value is registered in the list of values for a package type. This is parallel to how we replaced "known" with "registered" for PURL types.
• The description could be improved to: "Optional set of known namespace values for this package type. If provided, the namespace value should be one of these."
• Remove the CPAN change - it seems unrelated.
  Thanks