On Sat 2018-05-26 18:31:46 +0200, Patrick Brunschwig wrote: > 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.
Yes, i agree -- i'm not claiming that Enigmail is itself non-free, i'm saying that it depends on software that i can't sort out how to build reliably, which means i don't feel comfortable including that software in debian. > 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. understood :( I have the sense that the javascript ecosystem doesn't believe that reliable builds that don't require the internet are important, and that we should just all use npm and an active internet connection for everything. I would love it if i felt comfortable doing that, but it doesn't seem responsible to me. > 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/ ok, so this might be typically solvable if we can get GnuPG to fix: https://dev.gnupg.org/T3622 https://dev.gnupg.org/T3804 In the worst case, if the user is manipulating their keys outside of autocrypt and adding a bunch of new subkeys, the autocrypt header might be longer, but we can simply encourage people using autocrypt to not do that for the moment (so that we don't have to deal with this corner-case). Alternately, i can look into adding a GnuPG export option that does something like "export-autocrypt" which is designed to explicitly narrow down what is exported. > 2. Using GnuPG, you cannot guarantee that the Autocrypt Setup Message > (ASM) is encrypted with a specific password. See https://dev.gnupg.org/T3277 https://dev.gnupg.org/T3277 shows that there is a capability to do it, but you have to dance a delicate dance to ensure that it's done. I'll see what i can do to dance that dance in enigmail :/ > 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. I agree that using --list-packets is not acceptable, since GnuPG upstream refuses to support it as an API. > Run the unit tests in package. I think that almost everything covered by > tests, except for the ASM. thanks, i'll make sure to run both "check" and "unit". I note that i can't run the "eslint" part of the test suite on the debian build daemons, since eslint also hasn't been packaged yet for debian: https://bugs.debian.org/743404 clearly, the javascript ecosystem in debian is struggling :( If there's anything that you think needs eslint to ensure that things are OK, please let me know! > 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. I'm glad to hear this, and i hope i can pull off these changes as needed. I'll likely ask you for help if i get stuck, but i really appreciate your guidance so far. --dkg
signature.asc
Description: PGP 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
