If you’re talking about GnuPG, then absolutely. Why can’t we have something simple like signify, eh? If you’re talking about OpenPGP then, well, even with its issues, a suitable replacement would still needs its own RFC first :^)
Yes, it looks as if OSV could be fairly easily translated to VuXML and vice versa. They seem to capture the same information in an almost identical schema, just with different serialisation formats.
An RFC with no comparison against VuXML and which looks less useful. Yay?
It looks like it comes from an era (2003) when XML was quite fresh and cool(?). Is anyone apart from FreeBSD using it? It seems like if it’s never mentioned in duscussions about security.txt, then it’s mostl likely due to eveyone involved in VuXML either not being interested any more or asleep.
Human-readable is the new shit, next will be binary ;^)
I don’t know. I think NetBSD was, not sure if they still do.
It seems like if it’s never mentioned in duscussions about security.txt, then it’s mostl likely due to eveyone involved in VuXML either not being interested any more or asleep.
It looks as if I was misunderstanding the purpose of security.txt based on the title. It is about defining a way of reporting security vulnerabilities to the project, not a way for a project to report security vulnerabilities. The only consumer of this will be a human security researcher who has found a vulnerability. There is some value in having a convention here, but any text file is fine as long as it’s easy to find. I don’t care what the structure of the file is because a human will parse it and it will be a small part of the task of finding and documenting a vulnerability.
VuXML solves the other part of the problem. Every security vulnerability in a package shipped by FreeBSD gets an entry in the VuXML stream and it’s machine-parseable and easy to aggregate. It looks as if security.txt is designed to be machine-parseable (and therefore probably possible to aggregate) but it requires a bespoke parser. I’d love to see a VuJSON, since JSON parsers are simpler and more ubiquitous than XML these days.
The main value for this kind of thing is in auditing. On a FreeBSD system, I can type pkg audit and get a report of all packages with known vulnerabilities, generated from the VuXML. I believe Debian has something similar, though I don’t know anything about their implementation details. I can also build my own auditing tool and can easily produce a VuXML stream for my own package repositories that integrates with this.
It would be great if there were tooling to allow upstream projects to more easily publish their CVEs in machine-readable format that could be converted to VuXML. There’s a small ontology problem (VuXML tells you the range of versions for packages that are vulnerable but the versions of upstrea, of the FreeBSD packages, of the Debian packages, and so on don’t always align) but that’s something that could be solved with a bit of metadata in the packages allowing some tooling to handle the mapping.
I would rather see better tools than PGP for new standards.
If you’re talking about GnuPG, then absolutely. Why can’t we have something simple like signify, eh? If you’re talking about OpenPGP then, well, even with its issues, a suitable replacement would still needs its own RFC first :^)
Yes, makes sense.
Yeah, Signify would probably be much better.
Or reop, but you get the gist ;^)
I’m surprised reop hasn’t caught on like signify has (first time I’m hearing of it). Seems like a great tool.
An RFC with no comparison against VuXML and which looks less useful. Yay?
Would VulnXML be comparable to OSV? https://ossf.github.io/osv-schema/
Yes, it looks as if OSV could be fairly easily translated to VuXML and vice versa. They seem to capture the same information in an almost identical schema, just with different serialisation formats.
It looks like it comes from an era (2003) when XML was quite fresh and cool(?). Is anyone apart from FreeBSD using it? It seems like if it’s never mentioned in duscussions about security.txt, then it’s mostl likely due to eveyone involved in VuXML either not being interested any more or asleep.
Human-readable is the new shit, next will be binary ;^)
I don’t know. I think NetBSD was, not sure if they still do.
It looks as if I was misunderstanding the purpose of security.txt based on the title. It is about defining a way of reporting security vulnerabilities to the project, not a way for a project to report security vulnerabilities. The only consumer of this will be a human security researcher who has found a vulnerability. There is some value in having a convention here, but any text file is fine as long as it’s easy to find. I don’t care what the structure of the file is because a human will parse it and it will be a small part of the task of finding and documenting a vulnerability.
VuXML solves the other part of the problem. Every security vulnerability in a package shipped by FreeBSD gets an entry in the VuXML stream and it’s machine-parseable and easy to aggregate. It looks as if security.txt is designed to be machine-parseable (and therefore probably possible to aggregate) but it requires a bespoke parser. I’d love to see a VuJSON, since JSON parsers are simpler and more ubiquitous than XML these days.
The main value for this kind of thing is in auditing. On a FreeBSD system, I can type
pkg auditand get a report of all packages with known vulnerabilities, generated from the VuXML. I believe Debian has something similar, though I don’t know anything about their implementation details. I can also build my own auditing tool and can easily produce a VuXML stream for my own package repositories that integrates with this.It would be great if there were tooling to allow upstream projects to more easily publish their CVEs in machine-readable format that could be converted to VuXML. There’s a small ontology problem (VuXML tells you the range of versions for packages that are vulnerable but the versions of upstrea, of the FreeBSD packages, of the Debian packages, and so on don’t always align) but that’s something that could be solved with a bit of metadata in the packages allowing some tooling to handle the mapping.