Gnu Privacy Guard, a popular implementation of the OpenPGP standard, was found to have multiple vulnerabilities including modifying the plaintext shown to the user and modifying files on the user’s system.
As a background there is OpenPGP’s schism (article, thread). In 2018 or thereabouts there was a falling out between the current GnuPG developers and the current OpenPGP standard developers.
An important technicality is GnuPG is no longer (aims to be) compliant to OpenPGP (standard, website) but LibrePGP (standard, website).
I don’t understand the situation, but after reading this blog post my read on the situation is the GnuPG developers declare GnuPG complete and secure, and stubbornly refuse to improve/fix it. The argument to be cautious about changing the code is valid, especially in the context of GnuPG being used on many systems and vulnerabilities can cause real harm, but I worry about their resistance to fixing vulnerabilities, for instance the ones gpg.fail revealed.
Sequoia PGP is a competing OpenPGP CLI tool, covered here. I haven’t tried it and can’t vouch for the software nor developers yet.
just to dump a few things that i gathered over the last few months that i think are… nice to know.
ill rant a bit, sorry in advance.
generally yes, i just feel the need to point to this quote from the blog post:
If the old, audited, and battle-hardened 25-year-old code of GnuPG is secure and the critical security-relevant parts don’t change, there is no advantage to using a different programming language.
okay, this statement is very interesting. after semi extensive research (and you can correct me if im wrong) the only real evidence of an audit specific to gnupg was mentioned in this hacker news comment by a seemingly independant researcher. worst part was that some of his findings seem familiar in the context of the current gpg.fail disclosures. make of that what you will.
i think the “but we dont want to change” part from the blog post best illustrates, i cut this up into three distinct parts:
At GnuPG, we understood that unnecessary changes to a secure system pose risks that in our case nearly always outweigh the benefits. New code always contains bugs, and making changes without good reason only increases the chances of security issues.
the implication being that the old gnupg code doesnt contain bugs, which realistically even without the disclosure is just something you as a developer shouldnt assume. gnupg really has the ‘benefit of the doubt’ so to speak that if they claim they are audited the normal person just assumes they are. i mean foss projects get fuzzed by big companies all the time so its not hard to just assumed this will probably be done by someone somewhere for gnupg.
Since GnuPG is so widely deployed and so critical, our bugs can kill people, ruin lives, or throw the world economy into chaos.
let that sink in
So when we felt the churn interest had taken over, we gave up. At some point, I felt that the discussion switched from: “Why we must change this” to “Why don’t you want to change.”
this is just a catch all deflection. the whole article just tries to discredit criticism by masking it as some culture war bullshit (rust vs. c, foss vs. proprietary, old vs. new).
the last paragraph includes this:
“Lets throw away the company founder’s life’s work, 20 years of mature code, which is in use all over the world and has the highest reputation. To start from scratch! Because I know a better architecture! And Rust is cool! And to finance it, make it proprietary!”
sorry this isnt make a wish, your software can be 2 months or 30 years old, you could be writing that codebase by yourself and put a lot of effort into it but… that is by itself not a measure of quality, yet next to a claim of supposed audits it seems this is the only redeeming quality mentioned about the gnupg source repeatedly.
What I don’t get is do they affect the different package managers/update tools (such as RPM,APT,AUR,LVFS)?
On one hand I haven’t found anything about this but on the other :
-Everybody seem to use PGP
-Debian doesn’t seem to be in a hurry to fix one of the 2 vulns that got assigned a CVE among all of these and by the looks of it, they first provide a fix then issue a Security advisory.
Fedora seem to have patched a few of them and not having issued any special updates recommendations. “Verify the new update with the potentially flawed signing process” really sucks.
Would this be treated as a separate bug (with separate embargo period) if it could affect updates verification or does the evidence suggest we are clear ? An embargo sounds terrible as it wouldn’t really be a secret to somebody who has the skills to exploit such bugs.
Notes: In the past, the Kicksecure developpers issued special updates recommendations a few days after a Debian Security Advisory for a vulnerability in APT. Also note that it was treated as a “medium” security bug by debian. See Qubes Security Bulletin (QSB) #28: Debian update mechanism vulnerability | Qubes OS