The commenter from F5, MZMegaZone, seemingly the principal security engineer at F5, notes that “a number of customers/users have the code in production, experimental or not” and adds that F5 is a CVE Numbering Authority (CNA).
Dounin expanded on F5’s actions in a later mail response.
The most recent “security advisory” was released despite the fact that the particular bug in the experimental HTTP/3 code is expected to be fixed as a normal bug as per the existing security policy, and all the developers, including me, agree on this.
And, while the particular action isn’t exactly very bad, the approach in general is quite problematic.
Asked about the potential for name confusion and trademark issues, Dounin wrote in another response about trademark concerns: “I believe [they] do not apply here, but IANAL [I am not a lawyer],” and “the name aligns well with project goals.”
MZMegaZone confirmed the relationship between security disclosures and Dounin’s departure. “All I know is he objected to our decision to assign CVEs, was not happy that we did, and the timing does not appear coincidental,” MZMegaZone wrote on Hacker News. He later added, “I don’t think having the CVEs should reflect poorly on NGINX or Maxim. I’m sorry he feels the way he does, but I hold no ill will toward him and wish him success, seriously.”
Dounin, reached by email, pointed to his mailing list responses for clarification. He added, “Essentially, F5 ignored both the project policy and joint developers’ position, without any discussion.”
MegaZone wrote to Ars (noting that he only spoke for himself and not F5), stating, “It’s an unfortunate situation, but I think we did the right thing for the users in assigning CVEs and following public disclosure practices. Rational people can disagree and I respect Maxim has his own view on the matter, and hold no ill will toward him or the fork. I wish it hadn’t come to this, but I respect the choice was his to make.”
A representative for F5 wrote to Ars that:
F5 is committed to delivering successful open source projects that require a large and diverse community of contributors, as well as applying rigorous industry standards forassigning and scoring identified vulnerabilities. We believe this is the right approach for developing highly secure software for our customers and community, and we encourage the open source community to join us in this effort.
This post was updated at 8:15 p.m. ET on Feb. 15 to include a statement from F5.
