csaf_distribution icon indicating copy to clipboard operation
csaf_distribution copied to clipboard

Print provider-metadata.json files per domain

Open bernhardreiter opened this issue 1 year ago • 3 comments

A domain can have several provider-metadata.json (PMD) files (which each in turn can have several directory and ROLIE feeds).

To expose the discovery part of downloading, to be used by other components in a scripting environment, it maybe useful to have an option just to find and output all PMDs.

Use case: A script author wants to find if a domain offers CSAF 2.0 docs and all their PMDs to process them with no-go code/scripts.

bernhardreiter avatar Dec 14 '23 10:12 bernhardreiter

Hi, I would like to take care of this issue!

Here is what I understand: A provider can host several PMDs under one domain, using the three options well-known path, security.txt, and DNS-URL. Currently, the load function only looks for the first valid PMD it finds, but aggregators or other users may want to check for all PMDs that are hosted under a domain.

So I would add a function to providermetaloader.go, which already includes most of the necessary logic to enumerate all PMD files. I'd add a new function enumeratePMDs which obtains the PMDs from the well-known path and the security.txt. If these two do not include any results, it should check for the DNS-URL (as defined in the spec).

Additionally, the checker could be extended to use the new function.

immqu avatar Apr 22 '24 15:04 immqu

To clarify: The only way to specify one then on PMD is via the security.txt. See

  • https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#718-requirement-8-securitytxt
  • https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#731-finding-provider-metadatajson

If there is a DNS entry, it has to be the same as the well-known file.

Several PMDs in the security.txt shall only be temporary.

bernhardreiter avatar Apr 25 '24 07:04 bernhardreiter

To clarify: The only way to specify one then on PMD is via the security.txt. See

  • https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#718-requirement-8-securitytxt
  • https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#731-finding-provider-metadatajson

If there is a DNS entry, it has to be the same as the well-known file.

I have been discussing with @immqu internally and for us the standard is not 100 % clear on this. Requirements 7 seems to deal with the validity of a provide-metadata.json and requirement 9 is dealing with the well-known path. The DNS entry requirement (https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#7110-requirement-10-dns-path) points to requirements 7 and not requirement 9. @immqu will prepare an issue on the OASIS repo for this, that in general the requirements 7-9 need some clarifications from an implementers perspective.

The security.txt points to both 7 and 9, here its a little bit clearer.

Several PMDs in the security.txt shall only be temporary.

Edit: it seems there is already an ongoing discussion on this, https://github.com/oasis-tcs/csaf/issues/558, maybe we should continue there?

oxisto avatar Apr 25 '24 07:04 oxisto