Thanks for raising the issue, Robert. I think the move off of xul to
pure javascript is a good and healthy one regardless of any other
related (or unrelated) outcomes -- javascript is actually maintained,
and xul is on life support. Having a single simple codebase will be a
good thing.
That said, i think the specific question you raise below is worth more
consideration:
On Tue 2015-11-10 13:31:42 -0500, Robert J. Hansen wrote:
> To start things off, here's my contribution: what would people think
> about abandoning GnuPG in favor of moving to OpenPGP.js, a Javascript
> implementation of OpenPGP? This would make installing Enigmail vastly
> simpler, as we'd no longer have a dependency on a third-party
> application. Also, we'd only have to support one codebase, instead of
> dealing with people who were using GPGTools, GPG4Win, distro-provided
> GnuPG, and more.
I have no qualms at all about using OpenPGP.js for symmetric message
encryption and decryption. Indeed, it should be significantly faster
and less error-prone from an engineering standpoint than having to shell
out to a subprocess. And since the cleartext is available to enigmail
already (before encryption, after decryption), it's not clear that the
security boundary is much help, modulo protection of secret key
material.
So my two main concerns are around access to secret key material and key
management.
Access to secret key material:
Access to secret key material is something that could potentially be
solved by talking to a smartcard or a PKCS#11 module or to gpg-agent, or
all of the above, if necessary. Can Mozilla extension javascript talk
to a local agent socket?
if OpenPGP.js were used to access secret key material, are there any
steps that could be done to make it resistant to secret key leakage?
I'm talking about things as blatant as whether any other extension can
just extract the raw secret key by knowing the name of the variable.
I'm also talking about more subtly questions, like whether OpenPGP.js is
free of side-channel leakage.
Key management:
Key management is the Achilles heel of pretty much every user-facing
end-to-end public-key cryptosystem.
Currently, enigmail aims to integrate with GnuPG's key management; it
uses the GnuPG trust model, surfaces UI to expose its choices, relies on
it for key storage, and relies on its calculations for determining
whether a given key should be used or not.
An enigmail that doesn't attempt this sort of integration could
potentially have a much simpler interface, but it would not work well
for an existing userbase that has an OpenPGP keyring that is used with
GPG. If a translation tool was built to keep key management in sync,
how would that work? or would enigmail just give up on interoperating
with any other key management system?
--dkg
_______________________________________________
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
