Closed bernhardreiter closed 2 years ago
@sthagen Maybe, we should have a role CSAF downloader
? :thinking:
At first such a downloader role seemed over engineering, but given more details of real tool needs and the targeted high degree of (and reliance on) automation I am OK with such a role.
Just to clarify: the suggestion is to just add an order of preferences to ease the world for implementors of provider roles and consumers. In my view this could also almost be done editorial, as it would be fully compatible.
Well, order requires interpretation in implementer worlds. I assume it is a short circuit regime that interprets first one wins as the meaning of order, right? In a local context I understand that. In a remote context I am not so sure, because the DNS routes to dot well known and security.txt alike. I am OK with defining order and interpretation as editorial change.
Preliminary suggestion: We add a section about that in chapter 7.
Preliminary suggestion: We add a section about that in chapter 7.
specifically in section 7.1, correct? ... as we write the specific requirements in there and then refer back from the role sections in 7.2.
csaf 2.0 requires "CSAF providers" to check three places for the
provider-meta-data.json
file.https://github.com/oasis-tcs/csaf/blob/5ac8645b9da054634bc5e2810bcacce06dbf0c8e/csaf_2.0/prose/csaf-v2-editor-draft.md?plain=1#L5289
To ease and streamline implementations, we suggest to give an explicit order by which implementations reading CSAF conforming publishing sites should check for the file. This order should also correspond to what is prefered where providers (and aggregators) shall publish the
provider-meta-data.json
.This also affects the writing in requirements 7 to 10 as 7 gives suggestions without order and thus has an avoidable overlap with the different locations in 8,9 and 10.
(The suggestion from implementing https://github.com/csaf-poc/csaf_distribution is to check the .well-known location first, then security and then DNS.)