Is GnuPG substantively broken?
It depends.
One of the major problems with C and C++ is these languages are almost
perfectly designed to resist static analysis. (You can write
analysis-friendly C++ if you limit yourself to a subset, but the instant
you rely on any Cisms you open a gateway to hell. Abandon all hope, ye
who enter here.)
A few years ago at USENIX one of the interesting papers was on a Java
implementation of AES that had been formally proven to be correct. It
took the team about a solid year of work -- and they believed it simply
couldn't be done at all had they been working on a C version. I believe
them: just thinking about writing up Floyd-Hoare proofs with code that
relies that heavily on pointers and indirection is enough to make me
yearn for a nice career as a cake decorator.
The major technical shortcoming in C is its lackadaisical attitude
towards type safety and its habit of permitting implicit type coercions.
For instance, if I have a C enum value of { red, green }, I've just
defined a new data type that can be either red or green... but C will
happily allow me to convert a 0 into red and a 1 into green, and
vice-versa, without even giving a warning. Some people think this is a
feature: they're wrong. Think about it: wouldn't you like a warning of,
"Dude, we're turning numbers into colors: this LSD is pretty potent
stuff, man"?
In a strongly typed language like Ada this would be a compile-time
error; in the recent versions of C++ it would also be a compile-time
error; but C assumes the programmer is a synasthete for whom numbers are
colors and vice-versa, and so if it makes sense in the programmer's
world, why should the C compiler even issue a warning?
So, yeah. Security-critical code really should not be written in C
unless you're completely out of options. Something like the Linux
kernel, for instance -- good luck using anything but C to write an OS
kernel. (C++, maybe. Maybe. If you don't mind lobotomizing the
standard library and using a massively reduced subset.)
*But*.
Just because C is bad doesn't mean OpenPGP.js would be a better choice.
OpenPGP.js is a _javascript_ library, and _javascript_ has type conversion
issues that make C look like an abusive English public school
headmaster. Every bad thing I just said about C applies five times over
to _javascript_.
It really does seem to me that C or C++ are the best place to do
encryption.
C++, maybe, if you're careful. C is an awful choice, though.
If you're wondering why I'd throw out OpenPGP.js if _javascript_ is an
even worse language for high-reliability software than C, it's because
if OpenPGP.js is good enough for our purposes then switching over to it
would break our dependency on GnuPG. Enigmail would then be a single
plugin. We wouldn't have to deal with GnuPG-specific questions, we
wouldn't have to hand-hold users through setting up GnuPG.
It would be a serious win for us. But the question is ... is OpenPGP.js
good enough for our purposes?
_______________________________________________
enigmail-users mailing list
[email protected]
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
signature.asc