communication

Posted Jan 21, 2026 19:18 UTC (Wed) by Phantom_Hoover (subscriber, #167627)
Parent article: Responses to gpg.fail

Given the long-rising tensions between FOSS maintainers and security researchers I really think the latter should be thinking carefully about branding vulnerability drops with names like ‘gpg.fail’. I get that this stuff was fun and punky back in the day but security now has a big, boring and serious compliance industry attached to it and maintainers are already cracking under the strain; they don’t need their work insulted on top of that. At the end of the day, vulnerability disclosures by themselves do *nothing* to make anyone safer: they depend on the labour of maintainers patching them to materialise any actual benefit. So these researchers are part of a collaborative effort, and I don’t address my colleagues by getting up on stage and slating them for their epic fails.

to post comments

communication

Posted Jan 21, 2026 20:53 UTC (Wed) by tux3 (subscriber, #101245) [Link]

>At the end of the day, vulnerability disclosures by themselves do *nothing* to make anyone safer

Well, I was writing another response, but it vanished in a misclick. I'll say that at least for me, I'd heard of all those fancier modern alternatives and never had any reason to use them instead of good old battle tested GPG. I didn't expect GPG to be this complex internally, for what little use I make of it. I will be marginally safer, and I'll thank both the maintainers and the researchers.

I'm particularly impressed by the age maintainer, who responded by delivering an award in person to the researchers. My eyes can't help but see a contrast in the responses.

Disclosure timelines eventually end in publication of unpatched bugs. Vulnerability research can be inconvenient for compliance. I think that Compliance and security are just two very different axes, aren't they?

communication

Posted Jan 22, 2026 4:16 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (1 responses)

I totally agree with you. All these domain names, logos etc are only there to maximize the buzz that creates self-promotion for the security teams who find bugs. But they're not heroes, just code reviewers who find complicated bugs, and should be more respectful for the ones doing all the fixing work, very often in code they didn't write themselves, but only inherited from previous developers, or accepted from external contributions.

There can be plenty of reasons to criticize the gpg tool for being overly complicated to use, almost unusable in scripts not running in a tty, or for spawning an agent daemon even when you don't want one in recent versions, but this might just not be the right tool for certain tasks. And in any case it doesn't deserve insults like filing a domain such as this one, that the project maintainers will have no handle on regardless of their efforts to fix everything mentioned there.

When you think about it, for many OSS developers, the project they work on is an important part of their resume. Here, you apply for a job, proudly arboring 10 years in gpg, and the employer says "ah, yes, any responsibility in gpg.fail?". It's just not fair to force these people to justify themselves when everyone has been relying on their work, so I hope this domain will not be renewed once it expires.

communication

Posted Jan 25, 2026 17:04 UTC (Sun) by SLi (subscriber, #53131) [Link]

> There can be plenty of reasons to criticize the gpg tool for being overly complicated to use, almost unusable in scripts not running in a tty, or for spawning an agent daemon even when you don't want one in recent versions, but this might just not be the right tool for certain tasks.

Would you allow that there might some some responsibility for a developer of a major security tool that gains significant "not right tool" uses to be more vocal about it not being the right tool?

communication

Posted Jan 22, 2026 9:26 UTC (Thu) by neal (subscriber, #7439) [Link]

Disclosure: I'm one of the Sequoia PGP co-founders.

I fully agree with this comment: we need to tone down the language. If security researchers are professionals and intend to collaborate with maintainers, then sensationalism has no place in the discourse.

Relatedly, the security researchers want and deserve respect. But, it's hard to separate the wheat from the chaff and unfortunately the wheat to chaff ratio is very low. The Sequoia project receives multiple vulnerability reports per week. (This is partially because we have a bug bounty program, but a lot of reports are not submitted via the bug bounty program.) The reports are mostly convincing and invalid. This is because almost all---both the valid and the invalid ones!---are generated using AI. I simply cannot respond to most of them.

communication

Posted Jan 22, 2026 11:17 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link]

Well said. Thank you for this comment.

A few days ago we received a few other bug reports and one of them is indeed serious. As usual we work with them, fix the bugs, prepare new releases and publish this all. And than we can only hope that many sites will update to fix that vulnerability. Business and community work as usual.

communication

Posted Jan 24, 2026 14:34 UTC (Sat) by Heretic_Blacksheep (subscriber, #169992) [Link]

I don't agree. At all.

The reason I don't agree is because disclosure, regardless of how it's managed, prompts bad faith companies and even open source projects with self-promoted claims to security and quality to come clean or be proven to have no clothes. The bombast, if you will, actually started with grandiose claims by software companies and open source projects first (ex. OpenBSD's over-the-top security claims that have been walked back several times over the years).

Obviously, there's collateral damage to projects like cURL that try their best to Do The Right Thing without a lot of hoopla. What needs to change isn't necessarily the "tone", but the gating of quality reports, because some of these supposedly overblown inquiry results are not at all overblown, rather they're more like the preliminary steps that initiate repairs to the software code from organizations that would rather just sit on bad code indefinitely (*ahem* Oracle) till they take a PR/sales hit, or prompt people to move away to better maintained products or projects. This has been going on for years, and I doubt it's going to change. The question isn't what's "professional" or not, it's how open source projects deal with the not-really-new-but-definitely-evolving disclosure landscape.

The tone of professionalism is very much an opinion and one of culture. Some people don't like this, some don't like that. Others heartily approve something else entirely. As a case in point, many Americans often find The Register's tone as unnecessarily sarcastic, abrasive, and unprofessional, while many Brits see it as normal professional journalistic bombast.

These discussions are worthy to hold whether the problems were already known, or they're new. This industry has a serious problem with the New Kids ignoring the Old And Busted then tripping over stuff that was a known problem or "new" technique that's actually 20+ years old. GPG.fail was a mix of old and new, and they both needed to be (re)visited, and where necessary, pointed out that something that was a bad idea in 1996 but there was no way to change it then probably should have been removed by 2025 since a viable, more secure, replacement has been in place for what 10-15 of those years? Sure give people time to change over, but that shouldn't take more than 3-4 years tops, even if it's an enterprise (who will sit on broken tech indefinitely till they're forced to move by hook or crook).