Some reflections on OpenPGP, from the perspective of approaching Enigmail's end-of-life. Respect intended towards all, malice towards none, but a couple of sacred cows might get skewered along the way.
1/
1/
Everyone who says OpenPGP is embarrassingly ancient is right. Everyone who says it's bogus is wrong. The protocol itself is difficult to implement correctly and just feels clumsy and awkward by current standards. But for all that, it's still solid as a rock. 2/
In 15 years of supporting Enigmail users essentially every single day, *not once* did I see a security compromise traceable to a flaw in the protocol. Anyone proposing that OpenPGP should be replaced needs to answer the questions, "with what, and what's its track record?" 3/
In 15 years of supporting Enigmail users essentially every single day, I *constantly* saw pain points and failures from the ramshackle state of the OpenPGP ecosystem. It's bad. It's really, really bad. 4/
I give mad props to GnuPG for keeping a reference implementation alive for so long. I want GnuPG to continue supporting the latest and greatest in the OpenPGP spec. But I also think 99% of the projects incorporating it are doing it *very badly* -- sometimes Enigmail included! 5/
When TB calls Enigmail, Enigmail calls the shell, the shell calls GnuPG, etc., every one of those interface points is a possible interface break. And those interface breaks happened *a lot* and sometimes produced very serious security conditions. 6/
The #Efail attack? Interface break (and a bad one). Had no effect on the OpenPGP protocol.
If I could give security developers one bit of hard-learned advice from Enigmail: pay attention to your friction points and minimize them whenever possible. 7/
If I could give security developers one bit of hard-learned advice from Enigmail: pay attention to your friction points and minimize them whenever possible. 7/
Next: a much bigger problem than the OpenPGP protocol's antiquity and baroqueness is the near total lack of resources. The reason why GnuPG gets integrated into everything (when it was never designed to be integrated into *anything*) is because even today ... 8/
there is no high-quality OpenPGP library. (GPGME is an improvement, but still not there yet.) Enigmail was active for ~20 years and we were always so under-resourced we could never get around to implementing OpenPGP in Javascript to reduce our GnuPG dependency. 9/
But since OpenPGP.js (hi, @ProtonMail!), which has support from a company with good resources, we were able to rely on that more and reduce our dependencies on GnuPG... which in turn increased Enigmail's reliability by leaps and bounds. 10/
@ProtonMail Remember, it's not that GnuPG is bad! It's that *interface points are inherently risky*. TB->Enigmail->shell->GnuPG->shell->Enigmail->TB became TB->Enigmail->TB.
Mad props to GnuPG. You guys know I love you. But the standard GnuPG integration pattern is *awful*. 11/
Mad props to GnuPG. You guys know I love you. But the standard GnuPG integration pattern is *awful*. 11/
@ProtonMail So. Taking this to an overdue conclusion:
OpenPGP: old, baroque, kinda smelly. Works!
GnuPG: great ref. impl. but think hard about integrating it into your application.
Interface points: watch these traitors like they're going to stab you in the back, because they are.
12/12
OpenPGP: old, baroque, kinda smelly. Works!
GnuPG: great ref. impl. but think hard about integrating it into your application.
Interface points: watch these traitors like they're going to stab you in the back, because they are.
12/12
