Closed bernhardreiter closed 11 months ago
@JanHoefelmeyer please test if our finding algorithm finds the legacy /security.txt
without the wellknown part.
From staring at the code at
This is the wrong line. You wanted to mention: https://github.com/csaf-poc/csaf_distribution/blob/65fae93a812fdbae93f975dcfa61e031d131a419/csaf/providermetaloader.go#L135
This is the wrong line. You wanted to mention
Yes, thank you! I've corrected the main text above, so it reads better.
From my tests, I also reach the conclusion that the legacy path is not evaluated.
I also reach the conclusion that the legacy path is not evaluated.
Thanks for the confirmation, so the defect is confirmed. I keep the label "enhancement" because it currently is not in scope for running contracts.
Even if this is not part of a current contract I would opt to review and merge #506 before the final v3.
https://datatracker.ietf.org/doc/html/rfc9116#name-location-of-the-securitytxt has
From staring at the code at https://github.com/csaf-poc/csaf_distribution/blob/65fae93a812fdbae93f975dcfa61e031d131a419/csaf/providermetaloader.go#L135 I assume that we aren't supporting the legacy placement yet.
As https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#718-requirement-8-securitytxt refers to
Which refers to the RFC9116 again, the legacy location should be supported.