Since February, cryptographer Nadim Kobeissi has been trying to get code fixes applied to Rust cryptography libraries to address what he says are critical bugs. For his efforts, he’s been dismissed, ignored, and banned from Rust security channels.
On Tuesday, Kobeissi filed a complaint with the Rust Moderation Team and Leadership Council over the conduct of RustSec advisory database maintainers. Five hours later, he was banned from Rust Project Zulip spaces.
He then escalated his complaint to The Rust Foundation, claiming a Code of Conduct violation and citing the exhaustion of other avenues of redress.
“I am an applied cryptographer who discovered critical cryptographic vulnerabilities in the hpke-rs crate, including a nonce-reuse vulnerability enabling full AES-GCM plaintext recovery and forgery,” he wrote. “Over the past month, I have made repeated good-faith attempts to publish RustSec advisories for these vulnerabilities.”
Not everyone agrees with that assessment. Cryptographer Filippo Valsorda, whose November 2 bug report about a flaw affecting libcrux-ml-dsa v0.0.3 “sparked this whole saga,” told The Register in an email, “Kobeissi’s entire handling of the situation never seemed to be in good faith or proportional to me. He’s been attacking the Cryspen maintainers accusing them of ‘burying’ issues, for what in my opinion was unobjectionable behavior.”
Kobeissi took aim at Cryspen, a cryptographic software firm based in Paris, in a February 5 blog post, complaining that the company fixed the bug without “any public disclosure, security advisory, or acknowledgment that their ‘formally verified’ library had shipped with a defect that caused silent cryptographic failures in production environments.”
After Kobeissi published a link for his post to the Lobste.rs discussion forum, Valsorda acknowledged Kobeissi’s arguments about testing and engineering practices delivering better results for high assurance software than formal verification. But Valsorda also took issue with the way Kobeissi made his argument, calling it aggressive, accusatory, hyperbolic, and bordering on dishonest.
On February 25, Kobeissi made an online presentation at an Open Source Technology Improvement Fund meetup where he detailed concerns about 13 claimed vulnerabilities and the difficulties he had getting Cryspen, the maintainer of libcrux, to fix them.
Cryspen, in a response cited in Kobeissi’s presentation slides, said no bugs had been found in its verified code; Kobeissi said four had been found.
Invited to comment, Cryspen in an email said, “We welcome all vulnerability reports, and the bugs Mr. Kobeissi identified in our pre-release software were addressed within a week. Ultimately, discussions like this are valuable because they highlight the importance of being precise about the guarantees of formal verification, as we discuss in our blog post.”
By the admission of Cryspen co-founder and chief scientist Karthikeyan Bhargavan, under whom Kobeissi studied as a PhD student, “we did not do great with these advisories.”
Citing his difficulties working with the vendor and the lack of published security advisories, Kobeissi told The Register, “So basically there’s thirteen vulnerabilities. But let’s just focus on two, which are the really, really crazy ones that really need to have RustSec [publish security advisories] because they involve libraries that are being used by Signal, OpenMLS, Google, SSH, Linux kernel, all sorts of places.
“In both cases, I would argue, the vulnerabilities are critical. One of the vulnerabilities leads to full plain text recovery and message forgery – full key recovery for all messages after 2^32 encryptions. And the other one is a denial of service vulnerability. So the first one was actually deployed in Signal and in a bunch of other places. And so I felt it extremely important to have an advisory issued for this.”
In response to his efforts to have the RustSec team address these reports, Kobeissi claims the RustSec advisory database maintainer closed multiple advisory pull requests without technical justification, silently blocked him from the RustSec GitHub organization without notice, and closed his pending advisory pull request after he discovered he’d been blocked.
“The ban message cited ‘harassment’ – the same characterization used to dismiss my advisory contributions – and was imposed by the same individuals whose conduct I complained about,” he wrote.
The Rust Foundation on Friday acknowledged Kobeissi’s complaint, stating, “We take all reports very seriously. We will assess this in line with the Rust Foundation Code of Conduct Policy, which can be found on our website.”
The Register on Thursday asked the Rust Foundation for comment but we’ve not heard back.
Valsorda, who clearly would prefer not to be part of the online drama, contends that Kobeissi’s February 5 post misrepresents the situation by claiming to have found five security vulnerabilities when only one qualifies as a security issue – the nonce reuse bug reported to RustSec.
“The nonce reuse issue seems to be a valid security issue, but it is by no means a critical vulnerability: it only affects applications that do more than four billion encryptions with a single HPKE setup,” said Valsorda. “The average application does one.”
Valsorda said if the RustSec maintainers banned Kobeissi or chose not to merge his report, he’s inclined to believe they had reason to do so.
Pointing to Kobeissi’s outreach to The Register, Valsorda said the whole affair looks more and more to him like the harassment of open source maintainers.
The critical vulnerability of open source?
The debate underscores one of the longstanding challenges in open source software development – harmonizing behavioral norms across a diverse set of people, often volunteers, with different communication styles and expectations, and then adjudicating disputes amid potential conflicts of interest through organizational policies that lack the rigor and enforceability of court-based litigation.
Kobeissi makes this very point in his complaint to the Rust Foundation, arguing that the Rust Project’s moderation team representative on the Leadership Council is the same individual who issued a public moderation warning against him in the underlying security advisory dispute.
“He is both a participant in the conduct I am complaining about and a member of the body responsible for reviewing that conduct,” wrote Kobeissi, characterizing his ban as retaliation for complaining. “This is a direct conflict of interest.”
Kobeissi told The Register that he’s been trying to get an advisory for this bug for more than a month.
“It’s a critical vulnerability, and they’re stonewalling the publication of an advisory that is in the public interest, that is correctly formulated, that people need to have in their ‘cargo audit’ command so that they can learn about the vulnerability in a way that’s commensurate with its impact,” he said.
When one person’s passionate advocacy is another person’s zealous harassment, the critical vulnerability for open source might just be its people. ®
