| fungi | i'm beginning to think we should reconsider our position on cna-assigned cves for reports under embargo. when we request a cve reservation directly from mitre, we can also let mitre know to switch the information we supplied to public at the time we issue our advisory. if a cna assigns a cve, mitre does not have any information about the vulnerability and so can't make it public when | 14:54 |
|---|---|---|
| fungi | we're ready | 14:54 |
| fungi | in the future, i'm thinking we should refuse third-party cve assignments for private reports and request our own directly from mitre instead, in order to avoid the situation | 14:54 |
| fungi | i've half a mind to ask mitre to mark cve-2023-2088 rejected and request our own instead with the relevant detail included, but at this point the id has been circulated widely and referenced in our publications, so at this point we may just be stuck waiting for red hat security | 14:57 |
| SvenKieske | seems reasonable | 15:38 |
| SvenKieske | I don't know about this one, but sounds like a good policy going forward for all future such cases? | 15:38 |
| fungi | it's less of a concern for issues that are already public when a cve is assigned, but when we're doing coordinated publication yes it seems more straightforward for the vmt to interact with mitre in all cases (which is how we normally handle it, cna involvement under embargo is rare and was unintentional in this case in fact) | 15:40 |
| fungi | the alternative is to become a cna ourselves, it's been suggested by mitre in the past, but i feel like the volume of cves we request is below the threshold where that would make sense | 15:48 |
| SvenKieske | yeah I don't know about the operational overhead that being a CNA involves. | 16:29 |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline briefly for a patchlevel update, but should return to service in a few minutes | 20:42 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!