Yeah, very, very likely one and the same. Since 1989.
Can you say more about the CVE thing? That seems like the opposite of what Maxim Dounin was saying.
I don't know what else there is to say really. The QUIC/HTTP/3 vuln was found in NGINX OSS, which is also the basis for the commercial NGINX+ product. We looked at the issue and decided that, by our disclosure policies, we needed to assign a CVE and make a disclosure. And I was firmly in that camp - my personal motto is "Our customers cannot make informed decisions about their networks if we do not inform them." I fight for the users.
Anyway, Maxim did not seem to agree with that position. There wasn't much debate about it - the policy was pretty clear and we said we're issuing a CVE. And this is the result as near I can tell.
Honestly, anyone could have gone to a CNA and demanded a CVE and he would not have been able to stop it. That's how it works.
I get that CVEs have been politicized and weaponized by a bunch of people, but it seems weird to object that strenuously to something like this.
And appreciate the clarification about the CVE disagreement.
> Honestly, anyone could have gone to a CNA and demanded a CVE and he would not have been able to stop it. That's how it works.
I recently did exactly that when a vendor refused to obtain a CVE themselves. In my case, I was doing it as part of an effort to educate the vendor on how CVEs worked.
Even if third parties can file CVEs, do you think it hits different when the parent organization decides to do so against the developer's wishes? Why do he and F5 view the bugs differently? It sounds like the fork decision was motivated less by the actual CVEs and more about how the decision was negotiated (or not at all).
(PS. Thanks for participating in the discussion.)
