On 25.05.18 19:44, Daniel Kahn Gillmor wrote: > Hi Patrick-- > > thanks for your response on this! > > On Fri 2018-05-25 08:51:21 +0200, Patrick Brunschwig wrote: >> I cannot see a way out of this. Moreover, it's likely that OpenPGP.js >> will be used more in the future, because the native JavaScript API is >> _much_ simpler than calling Gnupg. > > it might be simpler for enigmail to use (i can see that!), but it's not > free software if we can't get all of the dependencies built from source. > And unfortunately, i can't seem to do that without allowing arbitrary > network access, or adding at least a dozen dependencies that i'm not > prepared to maintain in debian myself :/
Let's be fair ;). OpenPGP.js is LGPL, which is considered open source. The fact that Debian cannot handle the way that OpenPGP.js is built does not make it (or Enigmail) less open source, but is primarily a Debian-issue. I agree that it would be nicer if Enigmail were to build OpenPGP.js by itself, but just like you: I don't have the capacity for this. >> Enigmail currently relies on OpenPGP.js for quite a number of things >> where either output from GnuPG is insufficient, or the operation is much >> more complicated to perform with GnuPG than with OpenPGP.js, or the >> operation is not supported by GnuPG at all. > > It would be really helpful to me to try to enumerate the things that are > explicitly not supported. Many Autocrypt-related functions are not fully supported by GnuPG: 1. creating the Autocrypt header: the key is specified to contain exactly one UID one public/signing key and one encryption key. There is no function in GnuPG to extract this from a key. Users that have many UIDs or many subkeys keys cannot use Autocrypt with GnuPG because the header gets too long. See https://sourceforge.net/p/enigmail/bugs/731/ 2. Using GnuPG, you cannot guarantee that the Autocrypt Setup Message (ASM) is encrypted with a specific password. See https://dev.gnupg.org/T3277 3. You cannot check the packet list with GnuPG (which is again required before importing the ASM. Werner repeats that --list-packets is not meant for productive tools. > It'd be really great if there was a test suite that could exercise all > the expected functionality, so i could be sure my changes don't breaking > them. do you have anything like such a suite that i could piggyback on? Run the unit tests in package. I think that almost everything covered by tests, except for the ASM. > I'll be building an OpenPGP.js-free version of enigmail so that i can > ensure enigmail is present in debian, but would be happy to revert to a > version with OpenPGP.js if we can sort out how to get it built rather > than just copying a pre-built artifact! > >> OpenPGP.js is currently involved in the following functions (I'm not >> sure that this is a complete list): >> - importing public and secret keys >> - interpreting keys in Autocrypt headers >> - creating minified keys for Autocrypt headers >> - creating and processing Autocrypt Setup Messages > > Thanks, this is a good start. I'll be working through these one by one > -- some features might have to be cut initially to get this shipped > soon, but even if i cut them for now i hope to add them back in before > too long. > >> A possible workaround could be to offer downloading a prepared version >> of OpenPGP.js from a web service (obviously in a way that is acceptable >> for Debian, i.e. first ask the user for consent). > > hm, DFSG software needs to pass the "desert island" test: > > https://wiki.debian.org/DesertIslandTest > > If enigmail is unusable without OpenPGP.js, then either (a) we need > OpenPGP.js in debian, or (b) enigmail should be moved out of debian :/ > > Or, maybe enigmail is usable in a sensible way without OpenPGP.js? Enigmail is still usable in a sensible way without OpenPGP.js, and this will remain for quite a while. You'd need to cut off some parts, but these are not core functions. Probably the only exception is importing of keys, which would need some re-thoughts. > sorry to be forcing the issue -- i'm just at my limit in terms of what i > can reliably support in the free software ecosystem, and OpenPGP.js > appears to be the straw that is breaking the camel's back, as it were. > i'd love it if we could find a clean way to resolve this! -Patrick
signature.asc
Description: OpenPGP digital signature
_______________________________________________ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
