Re: [Enigmail] gpg / Enigmail behavior after disabling Gnome Keyring
On 12/14/2014 05:45 PM, Ian Mann wrote: > On 15/12/14 08:36, outa wrote: >> I recently upgraded to Kubuntu 14.10. Since then gpg started to show that >> warning message about Gnome Keyring hijacking it. So I disabled Gnome >> Keyring and switched to gpg-agent again, like before. However, each time I >> decrypt an email now, gpg asks for my passphrase (apprently not caching it), >> and each time I want to sign an email, it asks for a passphrase twice. >> Basically like described here: >> http://comments.gmane.org/gmane.comp.mozilla.enigmail.general/19022 >> >> This is odd and a bit annoying. Using gpg directly on the command line to >> sign a message results in only one passphrase prompt though. >> >> Has anyone experienced the same problem and could point me to a solution? >> Thanks a lot. > I had to uncheck PGP/Mime under settings, Open PGP Security. the PGP/MIME setting should have no bearing on gnupg prompting for a password more than once. outa, can you say what versions of software (gnupg, gpg-agent, and enigmail) you're using? gpg --version gpg-agent --version and the text from the top part of "About Enigmail" in thunderbird also, can you show the output of: grep use-agent ~/.gnupg/gpg.conf cat ~/.gnupg/gpg-agent.conf echo $GPG_AGENT_INFO ? the information above should help us figure out what's going on on your system and maybe we can find a fix. --dkg 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
Re: [Enigmail] Enigmail does not respect per-email encryption/signing settings
Hi Michael-- On 11/21/2014 11:54 AM, Michael Carbone wrote: > I draft an email to a recipient whose public key I have. I have signing, > encryption, and PGP/MIME on by default. I proactively turn off > encryption and/or signing, which is verified in the visual cues in the > Compose window as well as the Enigmail menu in the Compose window. I take it you mean that the menu items say "Force not to sign" and "Force not to encrypt" and the icons in the bottom right of the compose window have a blue circled exclamation point around them (tooltips "Message will not be signed" and "Message will not be encrypted") > However when I select Send, the confirmation dialog tells me that the > email will be sent encrypted and signed, overriding my very clear > instructions with this particular email to be unencrypted/unsigned. Which confirmation dialog are you talking about? I actually don't get such a confirmation dialog, though maybe i've turned it off somewhere. can you show the exact text of the dialog? > And > the subsequent email is indeed signed & encrypted, even though I have > explicitly set that particular email to be not. that's bad! > I thought the issue might be in Enigmail Preferences --> Sending with > the option Automatically Send Encrypted, as the language of the tooltip > suggests that only a per-recipient rule can override the setting, versus > manually override. However I changed it from If Possible to Never and > run into the same issue. What are your PGP/MIME settings for this account? If you're OK with sharing config details privately, can you send me the output of: egrep -i 'pgp|enigmail' .thunderbird/*.default/prefs.js (replace .thunderbird with .icedove if you're using debian's unbranded version). Does this happen with every contact whose keys you have? (feel free to experiment by sending me private mails as well, if you like) --dkg 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
Re: [Enigmail] difference in output between 1.4.x and 2.0.x when agent fails to sign -- causes enigmail to send broken messages
On 11/10/2014 11:51 AM, Ludwig Hügelschäfer wrote: > On 10.11.14 22:46, Daniel Kahn Gillmor wrote: > >> I'm not seeing either of these alerts when sending >> encrypted+signed messages with PGP/MIME using enigmail 1.7.2 and >> gnupg 2.1.0 on debian GNU/Linux, x86_64 (amd64) platform. > >> Are you sure you're doing encrypted+signed? are you also doing >> PGP/MIME? > > Yep. > >> Maybe there's a version/platform difference here? what are you >> using? > > This is on Mac OS 10.10, TB31.2 and the latest enigmail nightly. I > didn't use 1.7.2 What version of GnuPG are you using? Can you try with enigmail 1.7.2? I'd like to know if this is a bug due to the choice of platform (i.e. if we need to do something different on Linux than on Mac). --dkg 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
Re: [Enigmail] difference in output between 1.4.x and 2.0.x when agent fails to sign -- causes enigmail to send broken messages
Thanks for the prompt response, Ludwig! On 11/10/2014 11:25 AM, Ludwig Hügelschäfer wrote: > On 10.11.14 21:52, Daniel Kahn Gillmor wrote: >> * enigmail probably should detect that its invocation of gpg >> returns a non-zero error code and raise an error in the message >> creation step. I note that it appears to do so properly for when >> generating non-encrypted PGP/MIME-signed messages, it's just >> failing at PGP/MIME encrypted+signed messages. > > How exactly does this misbehaviour express to the user? I'm not > getting a falsely sent mail or a misleading error message. > > First Alert: > Error - encryption command failed > > Second Alert: > Sending of message failed. > Please verify that your Mail & Newsgroups account settings are > correct and try again. I'm not seeing either of these alerts when sending encrypted+signed messages with PGP/MIME using enigmail 1.7.2 and gnupg 2.1.0 on debian GNU/Linux, x86_64 (amd64) platform. Are you sure you're doing encrypted+signed? are you also doing PGP/MIME? Maybe there's a version/platform difference here? what are you using? Regards, --dkg 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
[Enigmail] difference in output between 1.4.x and 2.0.x when agent fails to sign -- causes enigmail to send broken messages
When creating a signed message (whether encrypted or not), if gpg-agent fails to sign the message, gpg 2.1.0 emits the first part of the message, but then terminates with a non-zero error code. gpg 1.4.x (and i think 2.0.x, but haven't tested today) both terminate with a non-zero error code but produce no output on stdout. This change in behavior causes problems with enigmail in particular, which appears to send the truncated results when producing a PGP/MIME encrypted+signed message if the agent fails to sign. I believe this is two distinct issues, and maybe we want to address them both: * gnupg 2.1.x might want to buffer data before the signature is made, and decline to emit anything if the signature fails * enigmail probably should detect that its invocation of gpg returns a non-zero error code and raise an error in the message creation step. I note that it appears to do so properly for when generating non-encrypted PGP/MIME-signed messages, it's just failing at PGP/MIME encrypted+signed messages. Below is a transcript showing the different behaviors between 1.4.18 (with --use-agent) and 2.1.0 when the agent fails to produce a signature. Regards, --dkg 0 dkg@alice:~$ gpg --version gpg (GnuPG) 1.4.18 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 0 dkg@alice:~$ gpg2 --version gpg (GnuPG) 2.1.0 libgcrypt 1.6.2 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 0 dkg@alice:~$ gpgconf --kill gpg-agent 0 dkg@alice:~$ gpgconf --launch gpg-agent 0 dkg@alice:~$ echo test | gpg --clearsign You need a passphrase to unlock the secret key for user: "Daniel Kahn Gillmor " 4096-bit RSA key, ID 0xA52401B11BFDFA5C, created 2013-03-12 (subkey on main key ID 0xCCD2ED94D21739E9) gpg: cancelled by user gpg: no default secret key: bad passphrase gpg: [stdin]: clearsign failed: bad passphrase 2 dkg@alice:~$ echo test | gpg2 --clearsign -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 test gpg: signing failed: Operation cancelled gpg: [stdin]: clearsign failed: Operation cancelled 2 dkg@alice:~$ echo test | gpg2 --sign --encrypt --armor -r $PGPID gpg: signing failed: Operation cancelled -BEGIN PGP MESSAGE- Version: GnuPG v2 hQIMA8Yb0+whSEz/ARAAnJCOUKoXQu0T0JCX3VmHzGW0HL5kvoZgrzYNzqfl2+0k HxKxZzic6sOuiXQ7GcZ6v6OuZy79brPU4vnpzy5DeeaVBE/6UKGhLVRQbaqFD74t PBVnwRdVKY7MHLeOn3H5H/CJRAqwXfYPBPTLEVb4HoJxtwR8GQcToqXTme42OHkd Vttfg6tUbfzwaqGuUHLVH12JP1g5Usq1RzhSbdrPBdB5bs4RNFkXYSW4hL2BWbvX ZoujMTXC+JwQJh5Edjav79rPXpCNuXZr6QS05FaDOfmDYRCSv+t1F1Yh0dIXwXcd h+TwJFGP27T/d2mE3o2uA1P1iZOh1V5czcNa2EwsE/My4/ou3kvSHMt8QhNIBJvB qENaQWM0hZKmPzlItc/J1oQW4BHvoOz5qNJxfxDw6aZrL7qP5+vgXD24JpR2DHzd 8/fi2QHsVnA7upMtfzaZ3x1jwbYxgM+/A3N8PdsKbyXu4SQwcvTmbRKgMx0L8DOJ hgsM/LrpuEJvpYAU7YSy2h5jANlNebhjGwfCDDmyR97BjXMcVt6BuJOS6JjN5plS RF6vrvdUD0NpJsPUkyVGD7RP6ofOScQ7oD8UfpegOldpK89U/3yJfk7yw2AYA0AI FZicmDyzWb/aKFbHzIMCi14u3x8BPSANfqnWv+/5yDsGkrydLWRMZeaeDZ9mgpg: [stdin]: sign+encrypt failed: Operation cancelled 2 dkg@alice:~$ echo test | gpg --sign --encrypt --armor -r $PGPID You need a passphrase to unlock the secret key for user: "Daniel Kahn Gillmor " 4096-bit RSA key, ID 0xA52401B11BFDFA5C, created 2013-03-12 (subkey on main key ID 0xCCD2ED94D21739E9) gpg: cancelled by user gpg: no default secret key: bad passphrase gpg: [stdin]: sign+encrypt failed: bad passphrase 2 dkg@alice:~$ 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
Re: [Enigmail] GnuPG 2.1.0
On 11/06/2014 06:11 AM, Bob Henson wrote: > I hear this morning that there is a new GnuPG 2.1.0 version which is > quite different from the 2.0.x versions. Will Enigmail continue to work > with this new version? Yes, i've been running enigmail 1.7.2 with the series of GnuPG 2.1.0 betas for over a month now. I don't expect that the official release version of 2.1.0 will cause a regression with respect to enigmail functionality. Note: I run debian testing/unstable, using the gnupg 2.1.0 packages from experimental (which i plan to update to the released version later today). --dkg 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
Re: [Enigmail] enigmal wrongly shows valid signature when an pgp/mime signed mail is attached
On 11/04/2014 11:39 AM, Daniel Kahn Gillmor wrote: > On 11/04/2014 10:58 AM, HW42 wrote: >> When an correctly PGP/MIME signed email is attached to an unsigned >> email enigmail wrongly verifies the attached mail and not the real mail. > > > yes, this is a problem, and was noted on this list back in march of 2013 :( I've reported this as a bug now so that it doesn't get lost again: https://sourceforge.net/p/enigmail/bugs/362/ I consider it a pretty serious flaw in enigmail's message verification. --dkg 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
Re: [Enigmail] enigmal wrongly shows valid signature when an pgp/mime signed mail is attached
On 11/04/2014 10:58 AM, HW42 wrote: > [I'm reporting this here and not on the bug tracker since I don't want > to agree to a few pages TOS for reporting a bug (sf account required)] > > When an correctly PGP/MIME signed email is attached to an unsigned > email enigmail wrongly verifies the attached mail and not the real mail. yes, this is a problem, and was noted on this list back in march of 2013 :( http://thread.gmane.org/gmane.comp.mozilla.enigmail.general/17707/focus=17839 The best proposed fix i've seen was from Eduard Christian Dumitrescu: http://thread.gmane.org/gmane.comp.mozilla.enigmail.general/17707/focus=17924 but i don't think anyone has implemented it. > > This is critical since this allows an attacker to write mails which > looks to the receiver as if they were singed correctly by another > person (If the attacker has access to one correctly singed PGP/MIME > mail from the person she wants to imitate). > > Steps to reproduce: > > - Write a PGP/MIME singed mail (use a subject without spaces). > - Forward the received mail as attachment and add some text. Don't sign > or encrypt the forwarded mail. You can add arbitrary text here. > - Open the forwarded mail. > In the last step enigmail shows the security info for the attached mail > and not for the content of the mail. Therefore you get a correctly > signed by ... message instead of the info that the content was unsigned. > > Tested with enigmail version 1.7.2 and thunderbird 31.2.0 (both the > debian as well as the archlinux versions are affected so that is > probably not distribution specific). agreed, i can confirm that this is also the case with enigmail 1.7.2 and icedove 33.0~b1 --dkg 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
Re: [Enigmail] Checking for keys in the compose windows
On 10/10/2014 09:50 AM, Tobias Hahn wrote: > Am 08.10.2014 um 17:27 schrieb Patrick Brunschwig: >> If you use the "convenient" composition mode (which means that >> emails are automatically encrypted if the keys for all recipients >> are found), then it's easy to determine if you got all keys: the >> key icon in the lower right corner is yellow if all keys are >> available and grey otherwise. > I'm using the convenient encryption mode, but had never noticed that > the icon changes colors depending on key availability. the color change is subtle (maybe too subtle? should we have visually distinct icons, like a lock or a lock with a circle/slash through it?) But i think it's also buggy (see the thread at [0]). I've just opened a bug report about it [1] so that the problem is tracked. Sorry to have not done that earlier, i thought i had. All the best, --dkg [0] http://thread.gmane.org/gmane.comp.mozilla.enigmail.general/18884 [1] https://sourceforge.net/p/enigmail/bugs/347/ 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
Re: [Enigmail] problems with auto-encrypt
On Sat 2014-07-12 13:09:35 -0400, Patrick Brunschwig wrote: > On 09.07.14 00:10, Daniel Kahn Gillmor wrote: >> i am seeing the following misbehavior with the 1.7 beta i packaged >> from yesterday (i have "convenient encryption" set as the >> default): >> >> When i reply to a message from someone for whom i have a key, more >> often than not, the default leaves the message unencrypted. >> >> When i send a new message to that person, or when i shift-tab up to >> the address bar and then tab back down to the subject entry box, >> the message becomes encrypted again. > > I can reproduce this. It is "just" a display problem. The logic works > correctly when sending the message, but the menu and the icons in the > lower right corner are incorrect. I'm still seeing this behavior in 1.7.2. It's pretty worrisome that these indicators aren't correct (in either direction -- though being incorrect in the other direction is unarguably worse). Has this issue been fixed since 1.7.2? --dkg pgpHMBYa4HjTd.pgp 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
Re: [Enigmail] Annoying Focus glitch
On 09/15/2014 06:33 AM, James Tandy wrote: > Alt-tab'ing to the window is not an option, as this popup window appears at > the very end of the window list, nowhere > near the thunderbird compose window. (Most irritating when you have like 15 > programs running) this isn't a fix at all, but a workaround to the specific problem you describe here: Alt+Shift+Tab cycles in the opposite direction from Alt+Tab, so it should be quick to get to the window from the keyboard. (note: i have not tested this with windows 8, but i know that it worked for every version of Windows i've ever used, and i assume it works for win8 as well) --dkg 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
Re: [Enigmail] importing keys in a message leaves wrong modification in resulting message
On 09/08/2014 02:05 PM, Olav Seyfarth wrote: > would you please open a minor bug for this issue? sure, here you go: https://sourceforge.net/p/enigmail/bugs/330/ Thanks, --dkg 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
[Enigmail] importing keys in a message leaves wrong modification in resulting message
i have a text/plain message, which has at the bottom of it an OpenPGP
key block ("-BEGIN PGP PUBLIC KEY BLOCK-", etc).
I have enigmail set to not decrypt or otherwise process text/plain
messages by default.
if i click "Decrypt" when viewing this message, I get a dialog asking:
Import public key(s) embedded in message?
[Cancel] [Import]
If i click "Import", then i get a dialog box telling me details about
what was imported, and my view of the message gets modified: the key
block is removed, and in its place are a few lins of text that look like
this:
--
* *BEGIN ENCRYPTED or SIGNED PART* *
** *END ENCRYPTED or SIGNED PART* **
--
Also, at the top of the message, i see:
--
Enigmail: *Parts of the message have NOT been signed or encrypted*
--
But in fact *none* of the message has been signed or encrypted, there
was just a free-floating keyblock.
I (think i) understand what's happening behind the scenes, but the
signals to the user are actually misleading here.
--dkg
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
Re: [Enigmail] case sensitivity in domain part of e-mail address matching
On 09/04/2014 03:43 PM, Olav Seyfarth wrote: > When you're logged in to SourceForge you should see a dark gray header bar on > https://sourceforge.net/p/enigmail/bugs/ - in its right, there's a mail icon. > "Subscribe" there. Thanks, Olav. I had missed that setting, as the mail icon didn't render in my browser for some reason. Regards, --dkg 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
Re: [Enigmail] case sensitivity in domain part of e-mail address matching
On 09/04/2014 02:22 PM, Doug Barton wrote: > On 9/4/14 11:14 AM, Daniel Kahn Gillmor wrote: > | I think opportunistic mode is matching based on case-sensitive > | e-mail addresses; while this is arguably appropriate for the > | local-part of the e-mail address > > The bug has already been identified and logged. :) I think you're talking about https://sourceforge.net/p/enigmail/bugs/323/ Is there any way that i can subscribe to the bug reports coming through that interface? I can't seem to find it, and i'm not always online when i'm finding these bugs. if they were in my local mail store, it would be a lot easier for me to make sure i'm not duplicating things. > And FYI, no, it's not appropriate to be case sensitive about either > part of the address. According to the RFCs, this is incorrect, and the local part is entirel up to the whims of the domain operator. But i agree with you that anyone running a mailserver where the local parts are case-sensitive on today's network is just asking for trouble. So i am quite happy to have the entire match be case-insensitive. --dkg 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
[Enigmail] case sensitivity in domain part of e-mail address matching
I think opportunistic mode is matching based on case-sensitive e-mail addresses; while this is arguably appropriate for the local-part of the e-mail address, the domain part should be matched in a case-insensitive fashion. For example: I'm using enigmail 1.7.2, with "convenient" opportunistic mode enabled. I have a key for Alice I go to compose mail to her, and for whatever reason, i write al...@example.net in the address bar. the e-mail will not be encrypted, despite the fact that all network resolution will treat the two e-mail addresses as identical. --dkg 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
[Enigmail] encrypting drafts without a keyID
hi enigmail folks-- reading the commentary in: https://sourceforge.net/p/enigmail/bugs/144/#665e suggests that the engimail preference to save drafts in encrypted form will only work if a keyID is set for the account preferences. Is this still the case? If so, i find it surprising that the preferences dialog box doesn't disable that checkbox when the radio button switches to "Use email address of this identity to select OpenPGP key". should i report this on the bugtracker, or reopen #144? If so, do you see it a bug in the dialog box UI, or is it a bug in the implementation? shouldn't we be able to use the same selection mechanisms to choose the key, and then just throw a warning if it can't find a selected key to encrypt each draft to. Regards, --dkg 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
Re: [Enigmail] overeager key user ID matching
On 07/25/2014 11:16 AM, King Ables wrote: > Of course, this only works on addresses already in your address book. > But it would give you an easy way to manually check an address before > using it. sure, but i already have an easy way to manually check an address before using it: gpg --list-keys al...@example.org the goal here is simplicity and ease-of-use -- the necessity of a workaround *is* the bug. --dkg 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
Re: [Enigmail] overeager key user ID matching
On 07/23/2014 04:03 AM, Olav Seyfarth wrote: > Could you please open a bug report for that? sure, done: https://sourceforge.net/p/enigmail/bugs/288/ > As a temporary workaround, please > use per receipient rules for those adresses that are matched falsely. The trouble is that i don't know which user IDs are likely to trigger this before i send mail. Even if i could rely on the key icon in the compose window to correctly indicate whether the message will be encrypted or not, without being able to see the selected key at send time i can't tell whether this is going to be a problem. Once i discover a given problem, i can set a per-recipient rule, but that'll only happen after i annoy my correspondent at least once (assuming they let me know, rather than just deleting the incomprehensible e-mail). :( --dkg 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
[Enigmail] overeager key user ID matching
hi enigmail folks--
Enigmail 1.7 is choosing the wrong key in some cases due to overeager
matching on the user ID. When matching for e-mail addresses, it needs
to make an *exact* match on the e-mail address, meaning that it is
either the entire User ID ("al...@example.com"), or that it is enclosed
in angle brackets ("alice ").
At the moment, if i have Alice's key, but i'm writing to the people
responsible for solid water at Example Corp (e-mail address
"i...@example.com" -- they don't have a key of their own) then enigmail
in "convenient mode" will happily encrypt to Alice's key, i think
because it found the string "i...@example.com" in her User ID.
I actually ran into this because i wrote to a friend j...@example.org
(who has no key that i know of), and my keyring knows of a
sarahj...@example.org, and Jane received an undecryptable message from
me. :(
--dkg
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
Re: [Enigmail] Finding public keys
On 07/15/2014 03:00 PM, Otto de Voogd wrote: > Actually, I'd like Enigmail to either show clearly that a key is revoked > (as one would see when querying the keyserver), or not show revoked keys > at all. The keyservers do not check whether the revocation is cryptographically correct, so their "(revoked)" is merely advisory. Even if they did check the cryptographic validity, you probably don't want to rely on them doing the check correctly (that is, the local client should verify the revocation anyway). I agree that the standard operation should be simpler from what the end user sees, but that doesn't mean that we should just believe the response from the keyserver directly. It may mean that we need to fetch more data and do some local processing on it before providing more UI, though. --dkg 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
Re: [Enigmail] unable to disable "Automatically Decrypt messages"
On 07/15/2014 01:50 PM, Doug Barton wrote: > For example, it's a fact that inline signatures work better with a wide > variety of software (MTAs, mailing lists, etc.). That's the chief "pro" > in terms of using inline. > > The chief "con" is that for people who receive the message who are not > using PGP it's "ugly" (which is to say that people sometimes do complain > about the "weird" stuff that is in your message). I'm frustrated to have to do this, but i do not think this is an accurate summary of the situation. MTAs are at least as likely to break inline message signatures as PGP/MIME-signed messages, and there are several other arguments against Inline PGP that i think are more important than things looking "ugly". I've documented some of them here: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ In fairness, i think the chief argument in favor of emitting inline PGP signatures is that there are apparently a few broken MUAs out there (apparently, some versions of android mail client and whatever windows offers as a free MUA) that don't know how to display a PGP/MIME-signed message properly, and fixing those clients is out of scope for this list. This will be my last message on this thread. --dkg 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
Re: [Enigmail] unable to disable "Automatically Decrypt messages"
On 07/15/2014 01:23 PM, Martin Vegter wrote: > What is the recommendation, then? > Should inline-PGP be used preferably, when sending plain messages > (without attachments) ? that's for your correspondents to decide, and not something you have control over there are much better arguments (in both directions) about whether to use PGP/MIME or inline-PGP than the argument that one or the other interacts differently with enigmail's "automatically decrypt" setting. This list has hosted several epic flamewars on the inline-pgp vs pgp/mime question over the years, it's probably not a great idea to start another one. --dkg 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
Re: [Enigmail] kmail encrypted/signed message unverifiable in enigmail
On 07/11/2014 11:43 AM, Daniel Kahn Gillmor wrote: > But i do see a signed tag enigmail-1-7 in the git repo from 2 days ago. > I'll go ahead and package that for debian :) Should i be looking > elsewhere for release announcements? hm. that signed tag for enigmail 1.7 contains a ./configure and configure.ac that seems to indicate that the version is enigmail 1.6. Attached is a patch that should fix this. hth, --dkg --- a/configure +++ b/configure @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.65 for enigmail 1.6. +# Generated by GNU Autoconf 2.65 for enigmail 1.7. # # Report bugs to <https://www.enigmail.net>. # @@ -551,8 +551,8 @@ MAKEFLAGS= # Identity of this package. PACKAGE_NAME='enigmail' PACKAGE_TARNAME='enigmail' -PACKAGE_VERSION='1.6' -PACKAGE_STRING='enigmail 1.6' +PACKAGE_VERSION='1.7' +PACKAGE_STRING='enigmail 1.7' PACKAGE_BUGREPORT='https://www.enigmail.net' PACKAGE_URL='' @@ -1174,7 +1174,7 @@ if test "$ac_init_help" = "long"; then # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures enigmail 1.6 to adapt to many kinds of systems. +\`configure' configures enigmail 1.7 to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1240,7 +1240,7 @@ fi if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of enigmail 1.6:";; + short | recursive ) echo "Configuration of enigmail 1.7:";; esac cat <<\_ACEOF @@ -1319,7 +1319,7 @@ fi test -n "$ac_init_help" && exit $ac_status if $ac_init_version; then cat <<\_ACEOF -enigmail configure 1.6 +enigmail configure 1.7 generated by GNU Autoconf 2.65 Copyright (C) 2009 Free Software Foundation, Inc. @@ -1374,7 +1374,7 @@ cat >config.log <<_ACEOF This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by enigmail $as_me 1.6, which was +It was created by enigmail $as_me 1.7, which was generated by GNU Autoconf 2.65. Invocation command line was $ $0 $@ @@ -3294,7 +3294,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1 # report actual input values of CONFIG_FILES etc. instead of their # values after options handling. ac_log=" -This file was extended by enigmail $as_me 1.6, which was +This file was extended by enigmail $as_me 1.7, which was generated by GNU Autoconf 2.65. Invocation command line was CONFIG_FILES= $CONFIG_FILES @@ -3347,7 +3347,7 @@ _ACEOF cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`" ac_cs_version="\\ -enigmail config.status 1.6 +enigmail config.status 1.7 configured by $0, generated by GNU Autoconf 2.65, with options \\"\$ac_cs_config\\" diff --git a/configure.ac b/configure.ac index bbb3d13..61929d7 100644 --- a/configure.ac +++ b/configure.ac @@ -2,7 +2,7 @@ AC_PREREQ(2.61) min_automake_version="1.10" -AC_INIT([enigmail],[1.6], [https://www.enigmail.net]) +AC_INIT([enigmail],[1.7], [https://www.enigmail.net]) AC_PATH_PROG(PYTHON, "python") 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
Re: [Enigmail] kmail encrypted/signed message unverifiable in enigmail
On 07/11/2014 11:32 AM, Patrick Brunschwig wrote: > Enigmail can decrypt/verify both methods. However, unless you use > Enigmail 1.7 (or nightlies) KMail emails cannot be verified correctly. Hm, i don't see a release of 1.7 on https://enigmail.net/ and there has been no announcement on this mailing list of an actual release, just a pending release. But i do see a signed tag enigmail-1-7 in the git repo from 2 days ago. I'll go ahead and package that for debian :) Should i be looking elsewhere for release announcements? fwiw, i'm running af19e586642d9, and one of these kmail encrypted+signed messages still doesn't validate (as reported here) and one does (the one samir sent). I'm following up with the author of the first message to see if we can get it to repeat, since both messages are validatable by a different MUA (notmuch). > See bug 209 (https://sourceforge.net/p/enigmail/bugs/209/) thanks for the reference. It looks like this was fixed in ab1b9a2d1c023c5bdf, right? this commit is already in the version of enigmail i'm running. Thanks for all your work on Enigmail. Regards, --dkg 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
Re: [Enigmail] kmail encrypted/signed message unverifiable in enigmail
On 07/11/2014 12:47 AM, Daniel Kahn Gillmor wrote: > Could you send me (privately) an encrypted and signed message with your > kmail instance? I don't care what it says, but leave the body as a > simple text/plain part -- no HTML formatting or attachments, and ask > kmail to sign/encrypt with PGP/MIME. Please encrypt it to my key > 0x0EE5BE979282D80B9F7540F1CCD2ED94D21739E9. > > I'll evaluate the structure and report back here on the list. Samir sent me a PGP/MIME-encrypted message from: User-Agent: KMail/4.13.2 (Linux/3.15.4-1-ARCH; KDE/4.13.2; x86_64; ; ) and it is structured in exactly the same way as the other Kmail message i reported. But enigmail is able to verify it, whereas the other one was unverifiable. It sounds like i need to go back to the original correspondent and clarify their configuration to see if i can replicate this with non-sensitive data. interestingly, i'm looking at enigmail's PGP/MIME-encrypted messages, and while they do bundle the signature directly into the encryption layer, the cleartext of the PGP block looks like this: D └┬╴multipart/mixed E └─╴text/plain I would have expected just: D └─╴text/plain Is there a reason that enigmail doesn't use the simpler structure? the multipart/mixed seems like a bit of unnecessary cruft around the message. Thanks Samir for your quick responses! --dkg 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
Re: [Enigmail] kmail encrypted/signed message unverifiable in enigmail
On 07/10/2014 06:18 PM, Samir Nassar wrote: > On Thursday, 2014-07-10 17:53:52 Daniel Kahn Gillmor > wrote: >> But i'm concerned because it seems like enigmail ought to be able to >> parse the kmail construction, at least if the top-level cleartext part >> is itself multipart/signed. > > I am happy to help. I'm running KMail 4.13.2, is your reference to kmail > 1.13.7 perhaps KMail 4.13.7 ? huh, weird. your mail header shows: User-Agent: KMail/4.13.2 (Linux/3.15.4-1-ARCH; KDE/4.13.2; x86_64; ; ) My other correspondent's mail header shows: User-Agent: KMail/1.13.7 (Linux/3.14-0.bpo.1-amd64; KDE/4.8.4; x86_64; ; ) It seems unlikely that they were actually using KMail 1.13.7 this week :) > If you need a KMail person to send emails back and forth for testing, I am > always happy to help. Could you send me (privately) an encrypted and signed message with your kmail instance? I don't care what it says, but leave the body as a simple text/plain part -- no HTML formatting or attachments, and ask kmail to sign/encrypt with PGP/MIME. Please encrypt it to my key 0x0EE5BE979282D80B9F7540F1CCD2ED94D21739E9. I'll evaluate the structure and report back here on the list. thanks for the quick volunteering, Samir! --dkg 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
Re: [Enigmail] problems with auto-encrypt
On 07/09/2014 05:20 AM, Olav Seyfarth wrote: > I don't see that behaviour here, so could you please be more specific on your > settings: > > - global sending settings "convenient" The "Sending" tab shows "Convenient encryption settings" is set. > - global key selection settings [X] By Per-Recipient Rules [X] By Email Addresses according to Key Manager [X] Manually if Keys are Missing [ ] Always (also) Manually > - per account default settings (detailed) [X] Enable OpenPGP support (Enigmail) for this identity (x) Use specific OpenPGP key ID [0xD21739E9] [ ] Encrypt messages by default [X] Sign messages by default [X] Use PGP/MIME by default After application of defaults and rules: [X] sign non-encrypted messages [X] sign encrypted messages [X] Encrypt draft messages on saving fwiw, i'm seeing this happen on multiple > - a debug trace (personal info obfuscated) What flavor of debug trace do you want? thunderbird can produce a lot of different ones. how would you like me to get it? Interestingly, in trying to reproduce it, i'm now seeing that it's easier to reproduce it (but not guaranteed) when replying to an encrypted mail, instead of just clearsigned mail. I haven't been able to get a coherent, reliable reproduction, unfortuantely. ah, heisenbugs :/ --dkg 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
[Enigmail] kmail encrypted/signed message unverifiable in enigmail
hi folks-- a friend recently sent me a PGP/MIME encrypted/signed message from k-mail 1.13.7. enigmail decrypted it but claimed "bad signature". Looking at it in more detail, i see that the message is structured like this: A └┬╴multipart/encrypted B ├─╴application/pgp-encrypted attachment C └─╴application/octet-stream inline [msg.asc] but decrypting C shows that inside C is: D └┬╴multipart/signed E├─╴text/plain F└─╴application/pgp-signature [signature.asc] The OpenPGP layer in C is *just encryption* -- no OpenPGP signature, which (i think) is why enigmail shows "bad signature". But the signature F is correct when calculated over E. I think enigmail's usual mechanism for constriction of PGP/MIME messages has part C contain the signature as well as encryption, and then part D is just the message itself. Both approaches seem valid from the perspective of RFC 3156, though the enigmail construction seems simpler. But i'm concerned because it seems like enigmail ought to be able to parse the kmail construction, at least if the top-level cleartext part is itself multipart/signed. Any thoughts? --dkg 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
[Enigmail] problems with auto-encrypt
i am seeing the following misbehavior with the 1.7 beta i packaged from yesterday (i have "convenient encryption" set as the default): When i reply to a message from someone for whom i have a key, more often than not, the default leaves the message unencrypted. When i send a new message to that person, or when i shift-tab up to the address bar and then tab back down to the subject entry box, the message becomes encrypted again. So something about the logic is misbehaving, i think. --dkg 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
Re: [Enigmail] last chance to beta test the upcoming version 1.7
On 07/07/2014 06:01 PM, Nicolai Josuttis (enigmail) wrote: > OK, thanks a lot. > We added a warning dialog for those switching to 1.7 yep, i did see the warning dialog. > to double check preferences > because we assumed that there are issues. > Although we didn't THAT issue. > Too much changes there is this something fixable before the release? --dkg 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
Re: [Enigmail] last chance to beta test the upcoming version 1.7
On 07/06/2014 03:57 PM, Nicolai Josuttis (enigmail) wrote: > after several months and a huge amount of updates, > Enigmail version 1.7 is close to be delivered. > While we still process all the translations, > the code and behavior should be done now. > > As we fixed a couple of bugs recently, we are looking > for final testers before everything gets freezed on Tuesday. > Thus, for those who have time to test enigmail, > please do so on Monday and send us detected bugs ASAP > (especially if these are significant bugs). thanks, i've gone ahead and uploaded a beta built from git commit af19e586642d into debian's experimental repository, so folks who are running debian can try fetching and testing from there. I noticed that when i built it, unused.txt was created with the following content: --- unused labels: enigmail.alwaysTrustSend.label enigmail.disableRules.accesskey enigmail.disableRules.label enigmail.encryptedsend.label enigmail.openpgp.label enigmail.sendPGPMime.label enigmail.setupWiz.details.subtitle enigmail.setupWiz.pgSign.noSign enigmail.setupWiz.pgSign.signAllMsg enigmail.setupWiz.pgSign.yesSign enigmail.signedsend.label unused properties: keyValid.valid --- Also, i notice that when i start composing a message, the message will be signed by default (That is, Sign messages by default used to be checked for me). looking at the preferences now, it looks like it is unchecked, but new messages are still signed by default. however, if i switch to "force sign", and then go back to "Use Defaults for Signing", the message switches to "Message will not be signed". When i check the preference checkbox manually (Enigmail > Preferences > Signing/Encryption Options…), then the "Use Defaults for Signing" behaves as expected. So i suspect that something about that preference didn't get transferred properly. Thanks for all your work on this. --dkg 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
Re: [Enigmail] Ubuntu uses old enigmail-Version
On 07/03/2014 08:18 AM, Philip Jackson wrote: > It is actually quite easy to download and install the latest version of > enigmail or even a nightly build. > > Download the version you want from Enigmail's website and then go to > Thunderbird : Tools/Add-ons. In the add-on manager, click the small down > arrow just to the left of the search box and select 'install add-on from > file'. The traditional recommendation of the Enigmail team is to get enigmail from whatever route you got thunderbird. That is, if you run a thunderbird installation that you got directly from mozilla.org, then get the enigmail plugin from addons.mozilla.org. If you run thunderbird from your operating system, get enigmail from your operating system. If that recommendation no longer holds, we should make a clear announcement about it someplace. --dkg 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
Re: [Enigmail] Request for Translation
On 06/30/2014 12:01 PM, Patrick Brunschwig wrote: > On 30.06.14 12:49, Kosuke Kaizuka wrote: >> - enigmail.keyservers.sample does not include >> pool.sks-keyservers.net > > Yes, we removed it. why? the currently listed example keyservers are: sks.dnsalias.net, pgp.mit.edu, ldap://certserver.pgp.com I think that keeping the pool in the example is probably a better for resilience, redundancy, and not putting too much strain on any individual keyserver. I suspect that people who don't know what to choose for this will copy/paste the defaults. It'd be nice to give them a default that's the well-maintained global pool. --dkg 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
Re: [Enigmail] 15 June nightly build
Hi Philip-- over on enigmail-users, On 06/16/2014 09:58 AM, Philip Jackson wrote: > me@me-desktop:~$ gpg --sign test-message > > You need a passphrase to unlock the secret key for > user: "Philip Jackson " > 2048-bit RSA key, ID 23543A63, created 2013-01-22 > (here I entered the passphrase) > gpg: problem with the agent - disabling agent use > gpg: can't open `test-message': No such file or directory > gpg: signing failed: file open error > > I tried a couple of times - same both times. is there a file named "test-message" ? you can find out with: ls -l test-message If that doesn't exist, you can create a simple text file with "example" in it with: echo example > test-message > command gpg-agent shows "gpg-agent: gpg-agent running and available" are you doing this from within a terminal emulator in a graphical environment, or are you doing this entirely from a text-mode virtual terminal? You might do better to debug this problem with gpg over on gnupg-users (i've cc'ed them here). If you want to follow up on that mailing list, you'll probably need to subscribe first at: http://lists.gnupg.org/mailman/listinfo/gnupg-users hth, --dkg 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
Re: [Enigmail] 15 June nightly build
On 06/15/2014 08:53 AM, Philip Jackson wrote: > But when I want to send a signed email, it presents first the OpenPgp > confirmation dialog and when I select OK, it immediately gives the error > message "Bad passphrase" without having given any opportunity to provide the > passphrase. you didn't mention what flavor of GNU/Linux you're using -- is it possible that you have gnupg installed, but not gpg-agent? whne you did your import, did you import the secret keyring as well as the public keyring? did you transfer your ownertrust database as well? (see the --export-ownertrust and --import-ownertrust actions for gpg) have you tried to use gpg from the terminal to sign a test message? if so, are there any error messages there? --dkg 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
Re: [Enigmail] on/off/default in a menu
Hi Nicolai-- On 06/06/2014 04:39 AM, Nicolai Josuttis wrote: > I am about to make the enigmail UI more convenient/self-explaining. > So, I have the following problem: > I want to give three choices for encryption (and other options): > 1) use default setting and rules > 2) turn encryption on > 3) turn encryption off > > Unfortunately there is no 3-way-toggle button. > But I want to give these three options in a menu. i'm assuming you're talking about the OpenPGP menu in a single compose window. is that right? At the moment, there are four options: Sign Message Encrypt Message -- Use PGP/MIME for This Message Ignore Per-Recipient Rules and they get little checkmarks when they're set. It seems like you could apply these options just for encryption, leaving the "Sign Message" alone, right? Is there some sort of "default" signing scenario that people might want to revert to? All the options presented seem rather clunky to me, and (worse) they present a problem for feedback -- if you're in the default state, looking at this state should let you know whether the given message is going to be encrypted or not. have you thought about how to address this view in the icons in the status bar (the pencil and the key) as well? Unfortunately, i'm having a hard time coming up with something better. I looked around at ideas about tri-stated checkboxes: https://en.wikipedia.org/wiki/File:Checkbox_States.svg http://guijournal.com/2011/05/gui-design-tri-state-checkboxes/ but they don't seem particularly useful to me. Here are the things i'd like to come out of this decision: 0) to see at a glance what the state of the message is 1) to know if i'm using the defaults or not 2) to be able to move from the default to a forced-setting other than the current default 3) to be able to move from the default to a forced-setting that is the same as the current default 4) to be able to move from one forced-setting to another 5) to be able to move from a forced-setting back to the default Some of these might seem more like things that humans want than others. (3), for example, seems unlike something that a regular human would think about. But it is relevant in the context of "as i write this draft, the defaults might change and i don't want to worry about that" If there are three (or four?) categories that i want to be able to have all these features on, it's pretty complicated! Here are two more proposals to consider: A) explicit default/non-default action What if the idea of deviating from the defaults was explicit and it covered all the settings at once? So the initial setup might look like: * Encrypt (default) Sign (default) * PGP/MIME (default) Lock these choices If the user chooses "Lock these choices" then they go to: * Encrypt Sign * PGP/MIME Revert to defaults (Encrypted, unsigned, PGP/MIME) Likewise, if the user chooses to alter any of the three items individually, *all* of them move off of "defaults" For cleanliness, the parenthetical in the "Revert to defaults" entry could dynamically only show the diff between the defaults and the current choices. So, for example, using the above defaults, but if someone clicked "Encrypt" (to disable encryption), they'd see: Encrypt Sign * PGP/MIME Revert to defaults (Encrypt message) B) submenus The OpenPGP menu would have three menu items which show the state (and whether they're a default) textually (not with a checkmark), and each of them have submenus. The submenu itself would change based on the state of the value: Encrypted (default) > Force Encrypted Force Unencrypted Signed (default) > Force Signed Force Unsigned PGP/MIME (default) > Force PGP/MIME Force Inline PGP then, if you were to select "Force Unencrypted" the tree would show: Unencrypted > Use Default (Encrypted) Force Encrypted If the current state had the default of Unencrypted, then it would look like: Unencrypted > Use Default (Unencrypted) Force Encrypted or if they're in the default state: Unencrypted (default) > Force Encrypted Force Unencrypted It still seems very complex for users to deal with, for something that is suppoesd to be more convenient/self-explaining :( what do you think? sorry to not have better suggestions. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] OpenSSL vulnerability
On 06/06/2014 02:40 PM, Robert J. Hansen wrote: > GnuPG uses libcurl to do things like access remote URLs. libcurl > depends on OpenSSL. fwiw, curl can be built against any of three possible crypto backends: OpenSSL, GnuTLS, or NSS (or it can be built without crypto at all, in which case it won't work with https). We're pretty far off-topic for the enigmail mailing list by now, though. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Documentation needs Update / Error Message
On 06/03/2014 06:17 PM, Daniel wrote: > Am 03.06.2014 23:48, schrieb Daniel Kahn Gillmor: >> the above doesn't look like it's being run from a cmd prompt. If >> you're running windows 7, click the start button, and then in the >> search box, type "cmd" (without the quotes) and hit enter. >> >> you'll get what passes for a terminal environment on windows. >> >> In that box, try running the gpg commands and seeing what output >> you get -- i think this should produce more copious logs than >> you're currently seeing. > > Dooh, youre right of course, i should go to bed... > > So cmd says: > > C:\Users\Daniel>gpg --charset utf-8 --display-charset utf-8 > --keyserver-options ca-cert-file=C:\Users\Daniel\s > ks-keyserver.netCA.pem --keyserver-options debug --command-fd 0 > --no-tty --batch --fixed-list --with-colons -- > keyserver hkp://hkps.pool.sks-keyservers.net:11371 --search-keys > susp...@gmx.de > gpg: suche nach "susp...@gmx.de" auf hkp-Server > hkps.pool.sks-keyservers.net > SEARCH susp...@gmx.de BEGIN > info:1:1 > pub:4229D21B:1:4096:1401723665:: > uid:Daniel :1401723665:: > > > SEARCH susp...@gmx.de END hm, i'm having a hard time reading the line breaks in this, and i'm also not seeing anything close to it when i do the search myself. I get *lots* more content, including indications of what IP address was used, etc. even if the certs don't match at least i get the following info from gpg 2.0.22: 0 dkg@alice:~$ gpg2 --no-tty --batch --fixed-list --with-colons --keyserver-options debug --keyserver-options ca-cert-file=/tmp/mysteryca.pem --keyserver hkps://hkps.pool.sks-keyservers.net --search susp...@gmx.de gpg: searching for "susp...@gmx.de" from hkps server hkps.pool.sks-keyservers.net gpgkeys: curl version = libcurl/7.37.0 GnuTLS/3.2.15 zlib/1.2.8 libidn/1.28 libssh2/1.4.3 gpgkeys: search type is 0, and key is "susp...@gmx.de" * Hostname was NOT found in DNS cache * Trying 162.243.93.15... * Connected to hkps.pool.sks-keyservers.net (162.243.93.15) port 443 (#0) * found 1 certificates in /tmp/mysteryca.pem * server certificate verification failed. CAfile: /tmp/mysteryca.pem CRLfile: none * Closing connection 0 gpgkeys: HTTP search error 60: server certificate verification failed. CAfile: /tmp/mysteryca.pem.pem CRLfile: none SEARCH susp...@gmx.de FAILED 1 gpg: key "susp...@gmx.de" not found on keyserver gpg: keyserver internal error gpg: keyserver search failed: Keyserver error 2 dkg@alice:~$ i'm not sure what to suggest. maybe someone with windows experience or a windows test installation can chime in here? --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Documentation needs Update / Error Message
On 06/03/2014 05:34 PM, Daniel wrote: > Am 03.06.2014 22:47, schrieb Daniel Kahn Gillmor: >> I don't know how to set the language environment to "C" in windows >> either, but let's go with this one for now. >> >> can you show a full cmd transcript of the above command, but also >> with --keyserver-options debug ? > > Just to be sure, the parameters added are now: > --keyserver-options > ca-cert-file=C:\Users\Daniel\sks-keyserver.netCA.pem > --keyserver-options debug > > Which gives me the same Problem: > enigmail> "C:\Program Files (x86)\GNU\GnuPG\pub\gpg.exe" --charset > utf-8 --display-charset utf-8 --keyserver-options > ca-cert-file=C:\Users\Daniel\sks-keyserver.netCA.pem > --keyserver-options debug --command-fd 0 --no-tty --batch --fixed-list > --with-colons --keyserver hkps://hkps.pool.sks-keyservers.net:443 > --search-keys susp...@gmx.de > gpg: suche nach "susp...@gmx.de" auf hkps-Server > hkps.pool.sks-keyservers.net > > gpg: Schlssel "susp...@gmx.de" wurde auf dem Schlsselserver nicht > gefunden > > > Or a succes without hkps:// > enigmail> "C:\Program Files (x86)\GNU\GnuPG\pub\gpg.exe" --charset > utf-8 --display-charset utf-8 --keyserver-options > ca-cert-file=C:\Users\Daniel\sks-keyserver.netCA.pem > --keyserver-options debug --command-fd 0 --no-tty --batch --fixed-list > --with-colons --keyserver hkp://hkps.pool.sks-keyservers.net:11371 > --search-keys susp...@gmx.de > gpg: suche nach "susp...@gmx.de" auf hkp-Server > hkps.pool.sks-keyservers.net the above doesn't look like it's being run from a cmd prompt. If you're running windows 7, click the start button, and then in the search box, type "cmd" (without the quotes) and hit enter. you'll get what passes for a terminal environment on windows. In that box, try running the gpg commands and seeing what output you get -- i think this should produce more copious logs than you're currently seeing. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Documentation needs Update / Error Message
On 06/03/2014 04:42 PM, Daniel wrote: > Am 03.06.2014 22:30, schrieb Daniel Kahn Gillmor: >> you may also want to add "--keyserver-options debug" to see more >> info. > > Not Working: > enigmail> "C:\Program Files (x86)\GNU\GnuPG\pub\gpg.exe" --charset > utf-8 --display-charset utf-8 --keyserver-options > ca-cert-file=C:\Users\Daniel\sks-keyserver.netCA.pem --command-fd 0 > --no-tty --batch --fixed-list --with-colons --keyserver > hkps://hkps.pool.sks-keyservers.net:443 --search-keys susp...@gmx.de > gpg: suche nach "susp...@gmx.de" auf hkps-Server > hkps.pool.sks-keyservers.net > > gpg: Schlssel "susp...@gmx.de" wurde auf dem Schlsselserver nicht > gefunden I don't know how to set the language environment to "C" in windows either, but let's go with this one for now. can you show a full cmd transcript of the above command, but also with --keyserver-options debug ? If it contains information you're not certain about, you're welcome to send it to me off-list, i just want to make sure we resolve the problem on-list. sorry i don't have a windows system handy to test it out with myself. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Documentation needs Update / Error Message
On 06/03/2014 04:22 PM, Daniel wrote: > Sorry, I forgot to mention, I already did this. i tried both methods, > manually editing the gpg.conf and the option in Enigmail. [...] > The System I'm currently running uses Windows 7 so thats not the Problem can you report the version of gpg you have installed, the version of enigmail, and the version of thunderbird? Can you look at the "Debugging Options" > "View Console" to see what the command is that's being run, and then try to re-run the exact same command from the command line, and report what the response is? you may also want to add "--keyserver-options debug" to see more info. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Documentation needs Update / Error Message
On 06/03/2014 12:03 PM, Daniel wrote: > i looked up the Docs on http://www.rainydayz.org/content/915-keyserver > Quote: "You may prepend a protocol to the name of a keyserver, e.g. > hkp://keyserver.example.com or ldap://certserver.pgp.com."; > > I tried and Enigmail 1.6 as well as today's nightly won't connect to > hkps://hkps.pool.sks-keyservers.net > using the search dialog in the key management menu. > > Enigmail does connect to hkps.pool.sks-keyservers.net, so this seems to > be a Enigmail Problem, either in the Docs or the Plugin? Using hkps properly (with certificate checking) requires setting up the root certificate authority. Without this, the connection will fail to validate. To do this, you need to fetch the root CA key for this pool [0], as described at [1]. Place this in a stable place (e.g. /home/daniel/sks-keyserver.netCA.pem ) and then tell enigmail to look for it. You can do this either by adding the following line to ~/.gnupg/gpg.conf: keyserver-options ca-cert-file=/home/daniel/sks-keyserver.netCA.pem or you can do it directly from Enigmail: OpenPGP > Preferences > "Display Expert Settings and Menus" > Advanced > "Additional Parameters for GnuPG" should contain: --keyserver-options ca-cert-file=/home/daniel/sks-keyserver.netCA.pem Once that's in place, you should be able to pull from the hkps pool. Does this work for you? Perhaps we should ship this root CA cert in enigmail directly, and default to using the hkps pool, or use it automatically if no other ca-cert-file option is set and the user has selected hkps://hkps.pool.sks-keyserver.net as their keyserver. Patrick, would you be willing to accept a patch for this? --dkg PS on debian and debian-derived systems, hkps is also only available if you have the "gnupg-curl" package installed. Without that package, hkps will fail regardless of the ca-cert-file, since you will just have the default shim keyserver transports. [0] https://sks-keyservers.net/sks-keyservers.netCA.pem [1] https://sks-keyservers.net/overview-of-pools.php#pool_hkps signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] PGP/MIME confirmation dialog
On 5/17/2014 10:51 PM, Someone wrote: >> Why not perform a check of the headers on all of the previously received >> mail from the email address you're presently sending mail to, and then >> skip the attachment scheme selection dialog if the contact's mail has >> been exclusively composed either on mail clients that support PGP/MIME >> or on ones that don't? I like the proposal of enigmail being more proactively helpful in figuring out what kind of message formatting is reasonable. On 05/17/2014 11:13 PM, Robert J. Hansen wrote: > A lot of users would object. "I don't want Enigmail to keep track of > whom I'm corresponding with and what technologies they're using! It's a > violation of privacy! How do I know what you're doing with that > information you're collecting?" > > And I hasten to add -- it's a pretty reasonable objection. I don't think this is a reasonable objection. Enigmail already has access to all of these mails. it's not like anyone is proposing sending this information to a network service or to the enigmail website or leaking this kind of private data. Users already expect Enigmail to handle more sensitive things (like the user's key material) without divulging them. Just to be clear: I don't know of any MUA that can handle/decrypt PGP-encrypted mail but *can't* handle/decrypt PGP/MIME-structured encrypted mail. All the PGP/MIME problems i've seen reported have to do with failing to read PGP/MIME-signed (but not encrypted) messages. I think there are engineering issues that might make the initial proposal difficult, though.I don't know that they're insurmountable (some will be answered with heuristics that won't always guess right), but you probably want to think through them in more detail before trying to implement something like this: * just because you've never been sent an e-mail from that user via a PGP/MIME-broken MUA doesn't necessarily mean that they never read mail on such a MUA. Sending is not receiving. * you'd need to enumerate which versions of which MUAs (with which plugins) are PGP/MIME-broken and keep that list up-to-date somehow. How does that interact with, say, webmail implementations? * some messages don't have any clear indication of what MUA they used. * someone who used a PGP/MIME-broken MUA 6 years ago may not still be using that MUA. should six-year-old mail still be relevant? Figuring out what sort of cutoffs are reasonable is non-trivial. * Imagine a user who has 300,000 message in their mail archive. You wouldn't want search all of those each time. so you'd want to keep some sort of state for each user that could be updated when new mail from that user was discovered by thunderbird. This doesn't necessarily just mean when new mail is fetched -- thunderbird could suddenly get access to an old mailbox, or a new folder could be published. how would you synchronize this cached state? --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] question regarding a new sending preferences layout
On 05/04/2014 11:41 AM, Phil Stracchino wrote: > It appears to em that terms like 'thorough', 'careful' are scarcely > even applicable to what you're trying to accomplish here. Mode 1 is > basically 'Encrypt whenever possible' or 'Encrypt always'. Mode 2 is > harder to define -- the best I can come up with is, 'Encrypt manually > ONLY'. In other discussions about crypto that aim for the idea of "whenever possible, even if i'm not sure of the proper identity or other details", the word that seems to have the most consensus behind it is "opportunistic". --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] test implementation for auto encryption available in test-branch
[skipping a bunch of discussion covered elsewhere in the thread and
jumping directly to the UI/UX proposals]
On 04/22/2014 05:00 PM, Philip Jackson wrote:
> What about some consideration of the time elapsed since [valid] status was
> conferred ?
Is this the right time limit that a user should be interested in? what
about duration since last use or something like that? compare the two
following scenarios:
i certified Joe's key a year ago and we never exchanged any e-mails
(signed or otherwise) after that.
i certified Mary's key a year ago and we exchange encrypted/signed
e-mails every week.
time elapsed since [valid] status conferred is the same in both cases.
I agree that a time limit indication could be useful, but it should
probably be "time since last observed/used" or something like that.
that's a little trickier to count, unfortunately, and i'm not sure if
the extra UI complexity is worth the tradeoff. but it's certainly worth
considering.
>> * if the user manually chooses to encrypt the message when some users are
>> not [valid, then the non-[valid] icons should be highlighted or made bigger
>> or flash or blink or something to draw attention to them.
>
> With a help message when the cursor is hovered over the icon.
yes, that would be great.
> and perhaps if the time since {valid] status was conferred is greater than
> some specified interval, something like this --
> "it is x months since you accepted this key/userid as valid, are you sure you
> still want to use it or would you like to re-check?"
if the user said "i'd like to re-check", what do you think enigmail
should do?
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] test implementation for auto encryption available in test-branch
On 04/24/2014 06:39 PM, Mike Acker wrote: > one more time: all that happens in ENIGMAIL calls GnuPG passing a user ( > -u ) argument . if that argument is just an e/mail address GnuPG won't > have enough information to find the key you want if there are two or > more keys in the keyring with that matching e/mail address. Sure it does. GnuPG is the tool that keeps track of the calculated validity of the user IDs it knows about. If you have two or more keys with the same User ID and one is valid for that user ID and one is not, it should choose the valid key. It does not, currently. > to be sure to get the right key you pass the fingerprint in the -u > argument and this is what the recipient rules are for As John pointed out, there are other good reasons for the recipient rules. The job of selecting the key that is best-bound to the e-mail address shouldn't need to be one of them, since gpg already has all of that information. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] test implementation for auto encryption available in test-branch
On 04/24/2014 04:59 PM, John Clizbe wrote: > Good luck with changing the behavior of GnuPG ;-) Werner has suggested that 2.1 would actually perform key selection differently, perhaps because the proposed keybox store has no innate sense of linear order in the first place. dunno when that'll happen, though :/ > Obviate? Eh, not so much. Key selection for encryption is only one use for P-R > rules. Whether to sign and/or encrypt, and Inline vs PGP/MIME decisions > outside of default account settings are also handled by per-recipient rules. > > I'm not saying key selection isn't an important use of P-R rules, but it's > hardly the /sine qua non/ of P-R rules. yes, these are good points, and i shouldn't have overlooked them. thanks for pointing them out. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] test implementation for auto encryption available in test-branch
On 04/24/2014 02:52 PM, Mike Acker wrote: > On 04/23/2014 10:33 PM, Daniel Kahn Gillmor wrote: >> FWIW, i fully agree that the right place to fix this misbehavior is in >> GnuPG itself, not in enigmail. I care about non-enigmail users of >> GnuPG, and i definitely don't want to have the headache of synchronizing >> key selection routines of multiple GnuPG-using applications. > gnupg doesn't have access to your email directory. > it has to be corrected in enigmail eh? why would access to the contents of my e-mail be a requirement to select a valid key based on an e-mail address? > which, as noted, is why they have per recipient rules I know that enigmail has these rules, and that they are a way to work around GnuPG's suboptimal key-selection-from-email-address routine. I think there may be better ways to resolve these issues if we consider all the pieces of the stack. I think GnuPG's key selection routines need to be improved, and that would obviate the majority of the need for per-recipient rules. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] test implementation for auto encryption available in test-branch
On 04/23/2014 09:18 PM, John Clizbe wrote: > Philip Jackson wrote: >> On 22/04/2014 01:30, Daniel Kahn Gillmor wrote: >> >>> Note that enigmail's current default behavior is to simply choose the >>> *first* key in GPG's keyring that claims to be associated with the e-mail >>> address in question. This is true, even if the first key in the keyring >>> with a given e-mail address is *not valid* for that e-mail address, and >>> another later key *is valid* for that e-mail address :( >> >> Whoops ! > > WRONG!!! > > Dan, I know you know better than this. This is *NOT* Enigmail's behavior. > It is the behavior of GnuPG. It is also one of the main reasons behind the > creation of Enigmail's per-recipient rules. Thanks for clarifying, John. Yes, this the result of enigmail relying on GnuPG to select the key, and GnuPG doing the laziest thing instead of the most reasonable thing. > If I tell GnuPG I wish to encrypt something to j...@foo.bar.tld, gpg will do a > sequential scan of my public keyring and will return and use the first usable > key with a matching email address. This is how GnuPG behaves and always has > behaved. > > Don't start whining that Enigmail should do it differently because you don't > like GnuPG's default behavior. Outside of setting up a PR rule for an email > address, Enigmail can only use the key that GnuPG selects. FWIW, i fully agree that the right place to fix this misbehavior is in GnuPG itself, not in enigmail. I care about non-enigmail users of GnuPG, and i definitely don't want to have the headache of synchronizing key selection routines of multiple GnuPG-using applications. For my own personal use, i manually reorder of keys in my gpg keyring to ensure that the first key is the "best" one. it's a pain to do, and keyring updates could easily insert new user IDs earlier in the keyring's sequential order than the current "best" key. in that case, i go manually reorder them again. If GnuPG just did key selection by choosing the first key with the highest known validity for the given user ID, we could do away with much of the extra fiddly bits that make this process so slippery and confusing. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] test implementation for auto encryption available in test-branch
Hi Nico--
thanks for your work on this; i'm really glad to see people thinking it
through in detail.
Responses in more detail below, along with a more radical proposal that
hopefully we can use to think through the desired behavior.
On 04/21/2014 04:11 PM, Nicolai Josuttis wrote:
> Let me try to find a wording both experts and novices can live with
> (IMO that's key for a better acceptance of PGP).
yes, clearer understanding is important.
> We have owners.
I'd say "we have keys", and there are people who control those keys.
Some keys might be held or controlled or owned by multiple people.
> We can specify how much we trust them.
since the term "trust" is so beleaguered, perhaps we should say "we can
specify how much we're willing to rely on any given key to certify other
certificates.
> We have keys.
> Keys belong to email addresses.
again, i'd say that keys are distributed within certificates, and (most)
certificates have e-mail addresses associated with them.
> So the hard part is how the following:
> - a key is valid means different thing for experts and novices
I think we should be talking about a (key,userid) being valid, or a "key
being valid for a given e-mail address". Saying "a key is valid" isn't
really what we want to say. In particular, a key could be valid for one
e-mail address, and it could be not valid for another e-mail address.
> - we trust a key is nothing useful for an expert
> but for a novice.
i'm not sure what you mean by this. can you explain more?
> Now we have to formulate an option:
> - we accept all keys except disabled/expired/revoked ones.
> AH, may be "accept" is a word we can use
> (I used it here incidentally...)
"accept" needs to be clearer, i think, because it may not be just "we
are willing to encrypt to this key" -- it may also be "we are willing to
believe that signatures made by this key actually come from the person
identified in the user ID of the key's certificate"
> So may be we allow to change both options into the following:
>
> Accepted keys to send encrypted:
> - All valid keys according to the web of trust
> - All except disabled/expired/revoked keys
how about:
For a given e-mail address, encrypt messages to:
* all keys valid for that e-mail address
* all usable keys that claim to belong to that e-mail address
Note that enigmail's current default behavior is to simply choose the
*first* key in GPG's keyring that claims to be associated with the
e-mail address in question. This is true, even if the first key in the
keyring with a given e-mail address is *not valid* for that e-mail
address, and another later key *is valid* for that e-mail address :(
> Automatically send encrypted
> - never
> - if we have accepted keys for all e-mail addresses
> And for the first option of the first option we NEED a very short but
> compelling explanation (ideally as help text),
> which I still try to find reading all the documentation.
> May be:
> - According to the web-of-trust, a key is valid if:
> - it is your key (has ultimate owner trust)
> - you signed it
> - another owner you fully trust signed it
> - at least 3 other owners you marginally trust signed it
this may or may not be true, depending on the certification patterns.
It's certainly possible for users of gpg to modify how gpg interprets
the network of identity certifications it knows about. See
"--marginals-needed" and "--max-cert-depth" and "--trust-model"
arguments to gpg.
> But, BTW, I just saw that we also use the term "trusted" instead of
> "valid" in the key manager.
> So currently "trusted key" is used more or less consistently
> as non-technical term for "valid key".
Any place you find enigmail using "trusted" to mean "valid" is a bug,
and needs to be fixed. it's not surprising that there are more cases
that still linger in the codebase; gpg didn't clarify its own
terminology until several years ago, and enigmail has done some cleanup
on this recently, but seems to be reintroducing some of the conflated
terminology in some places. We should really try to avoid that.
(for example, the recent "trust the keys of all recipients" should
probably be something like "don't validate keys of recipients" -- we
don't know if the keys in questions actually belong to the recipients,
and we don't plan to actually indicate any ownertrust in them)
> So, let me ask again:
> May be you and we all can live with the term "trusted key"
> (as contrast to trust for owners),
no, i think that's one of the root causes of a lot of ongoing confusion.
non-expert users and expert users alike will be confused if we use the
same term ("trusted") to mean two different things.
All of this discussion has me thinking more widely about what the ideal
user interface *should* be, if we could get to it, rather than making
incremental improvements. I've tried to do a brief sketch below on a
new UI proposal that i think would address these concerns more helpfully
for regular use. the proposa
Re: [Enigmail] test implementation for auto encryption available in test-branch
On 04/21/2014 07:09 AM, Nicolai Josuttis wrote: > Thanks a lot for this feedback, Daniel. > These are very compelling arguments. > Seems I fall into the trap of making it "too good". thanks for reading and taking this seriously. > The new approach I suggest would be just to offer: > > Automatically send encrypted? > - Never > - If all keys are known and valid yep, this looks pretty good. But you might instead want to phrase the last part as: "if we have valid keys for all e-mail addresses" conceptually, the thing we're hoping will be valid is the *certificate*, which is a combination of user ID and key material, along with some additional cryptographic assertions about it. A valid certificate mean "we believe that the key in this certificate belongs to the person identified by the user ID in this certificate". Note also that OpenPGP certificates can have multiple User IDs, and you might believe that one User ID is valid, but another might not be. For example, I recently acquired a new e-mail address, and added it to my OpenPGP certificate. I haven't called publicly for new certifications of that e-mail address, so most people are unlikely to have verified it. So when we say "we have a valid key" we're omitting a bunch of details. We're really trying to say "we have a key that we believe is correctly bound to a user ID for the e-mail address that you're sending this mail to". > And let the option > "Always trust people's keys" I think this option is misleadingly-labeled in the first place. It should say "use keys without verification" or "accept keys of unknown validity" or something like that. the point is (a) this is not "trust" in the OpenPGP sense of ownertrust, so this term should be avoided here and (b) the keys that you will use if you set this flag may or may not actually belong to the people to whom you are sending the mail, so "people's keys" is misleading on its own. > then have the effect whether this means again: > - (disabled:) > use the rules of the web of trust for validity > or > - (enabled) >auto send encrypted if all keys are known >and not disabled/revoked/expired/mistrusted. this makes sense to me (though see below about "/mistrusted") > So, my question is: > What is the right term for > "not expired and not revoked and not disabled" > (the term should work for non-experts). I'd use a term like "well-formed" or just "usable", but i don't know of any consensus around either of those terms. > Similar, do we have a term for > "not expired and not revoked and not disabled and not mistrusted"? again, what do you mean by "mistrusted" here. are we talking about ownertrust? saying "no ownertrust" on a given key should *not* be used as a proxy for saying "i do not consider this key valid" or "never encrypt to this key". For example, i could have a list of keys, including one for a friend of mine who i know is very sloppy with his cryptographic certifications. (e.g. i've seen him certify a key he pulled off of a web page without doing any form of double-checking). I know his key is his key, and i still prefer to send him encrypted mail where possible, but i never want to rely on his certifications. If you never want to use a given key for encryption, you should disable it; i'm not sure what we gain from throwing "mistrusted" into the mix when deciding about what keys to encrypt to; "mistrusted" answers an orthogonal question, and i don't think it should play into the decision-making process for encryption. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] test implementation for auto encryption available in test-branch
On 04/20/2014 07:12 PM, Daniel Kahn Gillmor wrote: > I think it's a really bad idea to make encryption contingent on trust > settings; it should only be contingent on validity. let me explain this a bit further: * setting non-zero ownertrust on someone's keys puts you at risk of being willing to believe any faulty certifications that they make. * therefore, you should only set ownertrust on a key if you think that the keyholder makes reasonable certifications. * any tool which changes its behavior in ways unrelated to reliability of a keyholder's certifications on the basis of how much ownertrust you've set on the key will encourage some people to set ownertrust for these other effects. * the result will be that those users will end up willing to rely on certifications that they really do not want to rely on. does this make sense? any auto-encrypt mode needs to be based strictly on certificate validity (for the e-mail addresses being sent to, not for any other User ID on the key), and *not* on key ownertrust. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] test implementation for auto encryption available in test-branch
Hi Nicolai, all-- On 04/20/2014 09:30 AM, Nicolai Josuttis wrote: > a first implementation to provide the ability to > automatically encrypt messages if all valid keys are known this is a neat idea, but... > without the need to have a rule for it > into the sub-branch (derived from master): > AutoSendEncrypted > > In fact, you can choose between: >> Automatically send encrypted? >> - Never >> No automatically encrypted sending except explicitly triggered by rules >> - With full trust >> Automatically send encrypted when all keys are known and valid and have >> full trust >> - With marginal trust >> Automatically send encrypted when all keys are known and valid and have at >> least marginal trust >> - With unknown trust >> Automatically send encrypted when all keys are known and valid and have no >> explicit mistrust the above terms are deeply confusing. "valid keys" are not the same as "trusted keys". In OpenPGP, a "valid" certificate means that we believe that the key belongs to the person named in the User ID. a "trusted" key means that we're willing to believe OpenPGP certifications made by this key. I think it's a really bad idea to make encryption contingent on trust settings; it should only be contingent on validity. Can you clarify this? regards, --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] "trust the keys of all recipients" is problematic text
On 03/26/2014 09:57 AM, Mike Acker wrote: > On 03/25/2014 06:21 PM, Daniel Kahn Gillmor wrote: >> hi enigmail folks-- >> >> 1ee310b5bcdb86f225cc11ca0ae2138a7aaba992 addresses bugs 212 and 179 with >> a menu option called "trust the keys of all recipients". >> >> I think what this implies is that when sending a message to >> f...@example.com, enigmail will just use the first key it happens to find >> in the user's keyring that has f...@example.co in one of its user ids. > it may be possible to correct this by setting a PGP rule on the address > book entry > I'm experimenting with this What do you mean "correct this"? This e-mail thread was not intended to be about whether this particular action is right or wrong, it was about whether the text accurately describes what is being offered. That said, I'd be very interested in a separate discussion about what kinds of key management workflows are sensible. Ideally, we'd think about this with respect to enigmail on its own, and how well enigmail can integrate into other programs that might use OpenPGP for the user. I have some vaguely-formed ideas about how to do this kind of thing in ways that would share these validity decisions across other users of GnuPG as well, using a designated separate/independent local (non-exportable) trusted key to record temporary acceptances as local-certifications on the keyring. maybe we should start this discussion as a separate thread? --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] "trust the keys of all recipients" is problematic text
hi enigmail folks--
1ee310b5bcdb86f225cc11ca0ae2138a7aaba992 addresses bugs 212 and 179 with
a menu option called "trust the keys of all recipients".
I think what this implies is that when sending a message to
f...@example.com, enigmail will just use the first key it happens to find
in the user's keyring that has f...@example.co in one of its user ids.
i think this is the wrong language to use for this feature, because it
conflates the idea of "trust" (which has a specific meaning about how
much you're willing to rely on certifications made by the keyholder)
with the idea of "validity" (how much you believe that a given key
belongs to the person/address named in the user ID).
I'm having a hard time coming up with a pithy replacement (possibly
because i'm not entirely sure this behavior is a great thing to do), but
i think it should be something like:
"encrypt this message regardless of key validity"
or
"don't check validity of recipient keys for this message"
or
"ignore key validity when sending"
also, i don't think this menu option should be present (or maybe it
should be greyed out) when the message is not intended to be encrypted.
Probably the text in the preferences pane ("Always trust people's keys")
should be changed as well to use more sensible language.
Lastly, in the "key management" dialog box, the "Key Validity" column
(should it be "UserID validity"?) should probably choose its values from
the set {invalid,revoked,expired,-,unknown,marginal,valid} instead of
{invalid,revoked,expired,-,unknown,marginal,trusted}
At the moment, it's possible to have a key that is "Key Validity:
trusted", but "Owner Trust: untrusted", which is a pretty confusing
thing to see.
I'm happy to send patches, unless people have objections to this sort of
vocabulary cleanup.
--dkg
PS i'm very happy to see the build system cleanup. it works well, and
has greatly simplified the debian packaging, which is awesome. i plan
to upload a git snapshot into debian experimental in the next day or two.
signature.asc
Description: OpenPGP digital signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Using Enigmail for mailing lists
On 03/16/2014 11:46 AM, Boris Month wrote: > me and some friends of mine want to exchange encrypted emails on our > mailing list. Does enigmail support encryption for multiple recepients? > How would you encrypt information on a mailing list? You might be interested in schleuder, which is an encrypted re-mailer that is actively-maintained: http://schleuder2.nadir.org/ You might also be interested in SELS, which isn't currently maintained, but has some interesting (and unusual) cryptographic properties: http://sels.ncsa.illinois.edu/ The enigmail-users mailing list we're using uses mailman, which doesn't support encrypted messages (this is a reasonable choice for a mailing list with public archives anyway). But Abhilash Raj has recently done a large chunk of work to try to get mailman ready to deal with cryptographically signed messages (i regret that i haven't had a chance to review it more closely -- maybe someone else wants to take a look?). If the key management is done sensibly, Abhilash's work should provide a great foundation to be able to have an encrypted mailman installation. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] message with unrelated header verification
hi enigmail folks-- i know a few people have reported seeing a message verification pane that was unrelated to the message shown beneath it. We just got another one of these reports at https://bugs.debian.org/739828 for version 1.5.2. Is this problem believed to be solved in more recent versions? I haven't been able to replicate it myself with 1.6 today, but maybe there's just a timing issue? If this is a known bug, is there a specific bug id i should look for? I wasn't able to find it at http://sourceforge.net/p/enigmail/bugs/search/. Thanks for any info you might shed on the situation, --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] [PATCH] use https for enigmail URL
--- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index f1b97c9..bbb3d13 100644 --- a/configure.ac +++ b/configure.ac @@ -2,7 +2,7 @@ AC_PREREQ(2.61) min_automake_version="1.10" -AC_INIT([enigmail],[1.6], [http://www.enigmail.net]) +AC_INIT([enigmail],[1.6], [https://www.enigmail.net]) AC_PATH_PROG(PYTHON, "python") -- 1.8.5.3 ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] How do I choose amongst multiple keys for a recipient?
On 02/05/2014 10:06 AM, Onno Ekker wrote: > Well, to me it would also make sense to encrypt to the newest key by > default (by creation date), which would eliminate the need to create a per > recipient rule in most cases... > Having per recipient rules also brings the necessity to manage and maintain > those rules. furthermore, for those of us who use GnuPG with MUAs other than enigmail, per-recipient rules in enigmail don't translate to the other clients, which creates a syncing problem. Unfortunately, gnupg is pretty silly about its default choice of key when asked for a match for a specific e-mail address: it chooses the first key with that address in its list of User IDs based on a sequential scan of ~/.gnupg/pubring.gpg. You can figure out what the sequential ordering is with: "gpg --list-keys ''" -- the order they are emitted is the order in the keyring. If your keyring has two keys, 0x and 0x, in that order in your pubring, both with the UID of "Alice ", and you want gpg to propose 0x when you send mail to al...@example.org, you'll need to remove 0x from your keyring and then re-add it (which moves it to the end). I use the attached simple bash script "bumpkeytoend" to do this sort of shuffling (it may not work with shells other than bash). In the above scenario, i'd invoke it as: bumpkeytoend 0x Note that the script is designed to preserve non-local signatures. Also note that although it prompts the user whether they want to "delete the key from the keyring", if they say "yes", the old key will be re-added at the end of the keyring. I haven't bothered to smooth out this clumsiness. Regards, --dkg #!/bin/bash set -e aa="$(gpg --export --export-options export-local --armor "$1")" gpg --delete-key "$1" gpg --import --import-options import-local <<<"$aa" signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] signing broken, sometimes
On 01/30/2014 09:08 AM, Nathan Andrew Fain wrote: > it appears the enigmail has issues when the text of lines will get > wrapped. What I believe is happening is that the signature is made > before the text is converted to its unformatted version and > line-wrapped. So, the signature is created on this email before this > line gets wrapped. Then when the signature is checked again after the > text has already been wrapped the new line breaks calls the signature to > fail. I confirmed this by taking the failing signature and mail and > removing all line breaks and then passing it through gpg. When doing > this the signature is successful again. This also explains why when > editing the failed mail as a new mail the signature does not fail as the > line wrapping is already applied in the new mail. Your current message was signed using inline PGP (i can confirm tha this most recent message you sent to the list appears to have a broken signature). Does the same problem happen for you when using PGP/MIME instead? --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] how to find out to which key a mail was sent
On 01/28/2014 02:35 AM, Patrick Brunschwig wrote: > gpg --list-packets This indicates which keys the given e-mail *appears* to be encrypted to; but without the secret key material for each key, it's not possible to verify that the message is actually decryptable by that key. That is, it's possible to create a PK-ESK OpenPGP packet with a spoofed target key ID field (and it's even documented in the spec that a target key ID field of all-zeros is commonly used as a "hidden" recipient). https://tools.ietf.org/html/rfc4880#section-5.1 This is probably not surprising if you've thought about the underlying math and the way it fits into the OpenPGP protocol, but it's worth noting explicitly, lest other folks get the idea that the presence (or absence) of a key ID in a PK-ESK on a given message is some sort of guarantee that the message is decryptable (or not) by that key. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Citation gone upon connection failure
On 01/24/2014 10:49 AM, Patrick Brunschwig wrote: > On 23.01.14 21:07, David wrote: >> Do I understand this correctly? This bug was discovered in 1.6, >> and still is, and that this bug is also present in 1.7a1pre? And >> still is unrepaired? > > > Yes, and the workaround is simple: press Ctrl-Z (undo) two or three times. Or use PGP/MIME, which is not affected by this problem. This bug only affects inline-PGP-signed messages. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] [PATCH] select only the first fingerprint for any key, instead of the last
On 01/10/2014 11:45 AM, Robert J. Hansen wrote: > Nothing can replace proper certificate validation. completely agreed. > If I have a > certificate 0xDEADBEEF that I have validated and signed, and someone > else maliciously inserts a certificate 0xDEADBEEF (a different cert, but > one that has the same short ID) into my keyring, well -- what of it? > It's trivial to tell the difference between a validated and an > unvalidated certificate. GnuPG will even give a conspicuous warning > about it. Right. But in this case, we shouldn't be referring to key IDs at all, but rather to real human-comprehensible data, like the User ID, or the key creation date. That is: if we're going to be referring to keys by things that are spoofable and relying on proper certificate validation to weed out bad keys, you are better off referring to the keys by human-sensible terms, rather than expecting humans to deal with hexadecimal gibberish. Even more strongly -- the thing the mail user agent cares about is (and should be) the User ID, not the key ID. Consider the situation when Alice's key has ID 0xDEADBEEF, and her friend Bob has a wicked sense of humor (or terrible luck), whose key (marked with his name and e-mail address) happens to have a short keyID that is also 0xDEADBEEF, it's conceivable that Carol could meet and verify the keys of both Bob and Alice's key. now both are valid. when carol sends mail to Alice, she should send it to the valid key *that matches alice's e-mail address* So key IDs + validity don't actually solve the problem of "which key should i use?" since both keys in the situation described have the same validity. And they're not human-comprehensible (hard to remember, hard to communicate to other humans). And they're not collision-resistant. And they are forgeable (short keyids trivially so). There is no good use case for key IDs that i can see. > Where I see the need for full fingerprint IDs is in those situations > where people have instructed GnuPG and/or Enigmail to consider all > certificates to be valid. My preferred solution for that is to tell > people to stop living in sin, not to tell them to shift to full > fingerprint identification. :) But we need fingerprint identification to be able to do certificate validation, which is the only way to "stop living in sin". So we need the fingerprint to be displayed correctly. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] [PATCH] select only the first fingerprint for any key, instead of the last
On 01/10/2014 04:56 AM, Patrick Brunschwig wrote: > I'm sure that adding "fingerprint" or "with-fingerprint" to gpg.conf > will cause more issues in Enigmail than just the one found in Bug 239, > including situations where Enigmail will fail because it requires that > the option is not present. I strongly recommend to NOT add this option > to gpg.conf. Can you point to some of these places? I've been using enigmail daily, with "fingerprint" in my gpg.conf for several months. I think including "fingerprint" in gpg.conf is important because if people are trying to refer to specific keys, i don't believe that either the short or long keyid is a reasonable identifier [0]. If enigmail needs to know what all command line options are to get stable output, as mentioned in the bug report [1], then the only way to do that robustly given gpg's lack of a --withough-fingerprint option is to explicitly add --fingerprint --fingerprint (twice so that we get subkey fingerprints too) to gpg every time too), and deal with parsing the output correctly. I'm happy to send a patch for this as well if you like. Patrick, if you could point out places where you think enigmail can't handle the presence of --fingerprint, i'm happy to try to send patches to fix them too. Regards, --dkg [0] https://www.debian-administration.org/users/dkg/weblog/105 [1] https://sourceforge.net/p/enigmail/bugs/239/#29bc signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] [PATCH] select only the first fingerprint for any key, instead of the last
This addresses http://sourceforge.net/p/enigmail/bugs/239/
---
ui/content/enigmailCommon.js | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/ui/content/enigmailCommon.js b/ui/content/enigmailCommon.js
index b10375c..e19d9b0 100644
--- a/ui/content/enigmailCommon.js
+++ b/ui/content/enigmailCommon.js
@@ -1008,7 +1008,10 @@ function EnigGetKeyDetails(sigListStr) {
subkeyList.push(aLine);
break;
case "fpr":
- fingerprint = aLine[9];
+ // only select the first fingerprint, in case the user has "fingerprint"
specified in gpg.conf
+ if (null == fingerprint) {
+fingerprint = aLine[9];
+ }
break;
}
}
--
1.8.5.2
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] default settings for key servers in enigmail
On 01/04/2014 11:34 PM, Kosuke Kaizuka wrote: > ha.pool.sks-keyservers.net is also a good candidate. > > https://sks-keyservers.net/overview-of-pools.php >> This is a high-availibility subset of the pool. At the moment it >> only includes servers running a reverse proxy rather than exposing >> sks directly to the clients. actually, kristian recently decided to make membership in pool.sks-keyservers.net require a reverse proxy, so there's no need to refer explicitly to ha.pool (see the thread on sks-devel that started on Oct. 28, titled "reverse proxies and the pool") Regards, --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] default settings for key servers in enigmail
On 01/04/2014 04:09 PM, Ludwig Hügelschäfer wrote: > pool.sks-keyservers.net yields 20 addresses, 10 IPv6, 10 IPv4. This is > the keyserver network I'm using and it worked reliably for me the last > years. > > keys.gnupg.net yields 20 addresses, 10 IPv6, 10 IPv4. Most of them are > identical to those from pool.sks-keyservers.net, and should be as > reliable as pool.sks-keyservers.net. 0 dkg@alice:~$ dig +short CNAME keys.gnupg.net pool.sks-keyservers.net. 0 dkg@alice:~$ :) > Enter pool.sks-keyservers.net or keys.gnupg.net should be entered first > in the list of keyservers. subkeys.pgp.net should neither be used nor > entered by Enigmail per default. I agree with this suggestion. Kristian has done a great job at making sure that the pool is functional and effective. it should be the standard default. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] behaviour of enigmail 1.6 in Thunderbird 24.2.0
Hi Philip-- thanks for your thoughtful review of these scenarios. i only have time to respond to one of them now, but i think they all warrant further review and probably some functionality changes. On 12/15/2013 12:43 PM, Philip Jackson wrote: [a bunch of good diagnostics snipped] > Fourth case : sender's key imported, Thunderbird restarted, trust level set > to > 'unknown' and sender's key signed by me. Thunderbird displays a green band > with > the message 'Part of the message signed; click on 'Details' button for more > information + key ID and date signed.' > > The date signed is given as today's date and the time as when the email was > first opened, I think - but I actually signed this key last October (according > to Kleopatra). In this case, enigmail is reporting the date that e-mail was signed, not that the sender's OpenPGP certificate (a.k.a. "public key") was certified. Since OpenPGP certificates are multi-issuer, there can be many certifications on any given cert, and they can all have different times. It only makes sense in this context for thunderbird to report the message signature time, i think. Is there a way you could re-phrase the enigmail header that would clarify that the time/date reported is the message signature timestamp instead of the certificate's certification timestamp? --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Key not found or not valid
On Wed 2013-01-16 09:12:09 -0500, Patrick Brunschwig wrote: > On 15.01.13 21:10, Daniel Kahn Gillmor wrote: >> Question B -- >> >> Would patches be welcome to improve the terminology around validity >> and trust? > > Sure, yes :-) It's been a while, but I've finally sent a patch to the list that resolves one of the major discrepancies: https://lists.enigmail.net/pipermail/enigmail-users_enigmail.net/2013-December/001182.html but none of the patches in that set have had any response on the list. maybe they got filtered out somehow? anyway, feedback is welcome! Regards, --dkg pgp534d5sT68t.pgp Description: PGP signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] "Automatically decrypt/verify messages" not working in 1.6 or 1.5?
On 12/14/2013 09:23 AM, Patrick Brunschwig wrote: > On 13.12.13 22:29, Daniel Kahn Gillmor wrote: >> in http://bugs.debian.org/732067, a user reports that the checkbox >> "Automatically decrypt/verfiy messages" in the OpenPGP menu isn't >> working any more. > >> Apparently, the menu option is only available when "show expert >> preferences" is chosen in the OpenPGP preferences dialog. > >> The inital report came in about version 1.5, but i can confirm the >> same misbehavior with 1.6. > >> can other people test if this option works for them? > > Please re-read the bug report. It is not about "Automatically > decrypt/verfiy messages" but about the fact that the user has to type > the password every time. The menu option is about attempting to > decrypt the email, and not related to any password timeout settings... I agree that the report mixes the two things; but i'm pretty sure the issue is about "automatically decrypt/verify messages". I've asked the original reporter to clarify on the bug report; hopefully that will help. Anyhow, in my testing, it does look to me like the "automatically decrypt/verify messages" checkboxed menuentry doesn't have the desired effect, at least on icedove 24.1.1 and enigmail 1.6. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] "Automatically decrypt/verify messages" not working in 1.6 or 1.5?
in http://bugs.debian.org/732067, a user reports that the checkbox "Automatically decrypt/verfiy messages" in the OpenPGP menu isn't working any more. Apparently, the menu option is only available when "show expert preferences" is chosen in the OpenPGP preferences dialog. The inital report came in about version 1.5, but i can confirm the same misbehavior with 1.6. can other people test if this option works for them? --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] [PATCH 1/4] avoid mixing declarations and code for compliance with C90
Without this patch, pedantic C compilers will choke with messages
like:
ipc/src/subprocess.c:71:5: error: ISO C90 forbids mixed declarations and code
[-Werror=pedantic]
int countFd = 0;
^
ipc/src/subprocess.c:91:5: error: ISO C90 forbids mixed declarations and code
[-Werror=pedantic]
int i;
^
ipc/src/subprocess.c:60:15: error: unused variable ‘fd’
[-Werror=unused-variable]
int *const *fd;
^
cc1: all warnings being treated as errors
make: *** [ipc/src/subprocess.o] Error 1
---
ipc/src/subprocess.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/ipc/src/subprocess.c b/ipc/src/subprocess.c
index 92d20b5..5343120 100644
--- a/ipc/src/subprocess.c
+++ b/ipc/src/subprocess.c
@@ -57,10 +57,11 @@ pid_t launchProcess(const char *path,
pid_t pid;
int mergeStderr = (fd_err ? 0 : 1);
- int *const *fd;
pid = fork();
if (pid == 0) {
+int countFd = 0;
+int i;
/* child */
if (workdir) {
if (chdir(workdir) < 0) {
@@ -68,7 +69,6 @@ pid_t launchProcess(const char *path,
}
}
-int countFd = 0;
while (dupFds[countFd] > 0) {
++countFd;
}
@@ -87,13 +87,10 @@ pid_t launchProcess(const char *path,
dup(mergeStderr ? fd_out[1] : fd_err[1]);
-
-int i;
for (i=0; ihttps://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] [PATCH 2/4] All keys should be shown by default in the key manager
the key manager's "Show all keys by default" checkbox is useful mainly
for people with large keyrings, who are likely to be experienced
users.
An experienced user can check the box and won't mind doing so. The
default case should therefore be for inexperienced users, who would be
otherwise baffled by the empty list of keys, even though they know
they have a few keys fetched already.
---
package/prefs/enigmail.js | 2 +-
ui/content/enigmailKeyManager.xul | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/prefs/enigmail.js b/package/prefs/enigmail.js
index d891850..23d5d91 100644
--- a/package/prefs/enigmail.js
+++ b/package/prefs/enigmail.js
@@ -119,7 +119,7 @@ pref("extensions.enigmail.logDirectory","");
pref("extensions.enigmail.keepSettingsForReply",true);
// display all or no keys by default in the key manager
-pref("extensions.enigmail.keyManShowAllKeys",false);
+pref("extensions.enigmail.keyManShowAllKeys",true);
// list of keyservers to use
diff --git a/ui/content/enigmailKeyManager.xul
b/ui/content/enigmailKeyManager.xul
index 6d52a86..82973ce 100644
--- a/ui/content/enigmailKeyManager.xul
+++ b/ui/content/enigmailKeyManager.xul
@@ -403,7 +403,7 @@
oncommand="onSearchInput();"/>
--
1.8.5.1
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] [PATCH 4/4] User Selection dialog should say "Validity" instead of "Trust"
The data shown in the "Trust" column of the User Selection dialog box
is actually the validity of the User ID, not the ownertrust in the
key.
This fix aligns this column header in the User Selection dialog with
the similar column header in the Key Management dialog.
---
src/nsEnigMsgCompose.cpp | 3 +--
ui/content/enigmailUserSelection.js | 28 ++--
ui/content/enigmailUserSelection.xul | 4 ++--
ui/locale/en-US/enigmail.dtd | 1 +
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/src/nsEnigMsgCompose.cpp b/src/nsEnigMsgCompose.cpp
index 2bc3f7a..bd4928a 100644
--- a/src/nsEnigMsgCompose.cpp
+++ b/src/nsEnigMsgCompose.cpp
@@ -77,10 +77,9 @@ nsEnigMsgCompose::nsEnigMsgCompose()
nsEnigMsgCompose::~nsEnigMsgCompose()
{
- nsresult rv;
#ifdef FORCE_PR_LOG
nsCOMPtr myThread;
- rv = ENIG_GET_THREAD(myThread);
+ ENIG_GET_THREAD(myThread);
DEBUG_LOG(("nsEnigMsgCompose:: > DTOR(%p): myThread=%p\n",
this, myThread.get()));
#endif
diff --git a/ui/content/enigmailUserSelection.js
b/ui/content/enigmailUserSelection.js
index baaba7e..da462fc 100644
--- a/ui/content/enigmailUserSelection.js
+++ b/ui/content/enigmailUserSelection.js
@@ -518,16 +518,16 @@ function enigmailBuildList(refresh) {
// create a (sub) row for the user tree
-function enigUserSelCreateRow (userObj, activeState, userId, keyValue,
dateField, trustStatus, uidValid) {
+function enigUserSelCreateRow (userObj, activeState, userId, keyValue,
dateField, uidValidityStatus, uidValid) {
var selectCol=document.createElement("treecell");
selectCol.setAttribute("id", "indicator");
- var trustCol=document.createElement("treecell");
+ var uidValidityCol=document.createElement("treecell");
var expCol=document.createElement("treecell");
var userCol=document.createElement("treecell");
userCol.setAttribute("id", "name");
expCol.setAttribute("id", "expiry");
- trustCol.setAttribute("id", "trust");
+ uidValidityCol.setAttribute("id", "validity");
userCol.setAttribute("label", userId);
expCol.setAttribute("label", EnigGetDateTime(dateField,true, false));
@@ -540,36 +540,36 @@ function enigUserSelCreateRow (userObj, activeState,
userId, keyValue, dateField
keyCol.setAttribute("label", EnigGetString("keyTrust.group"));
keyCol.setAttribute("id", "keyid");
- var trust=EnigGetTrustLabel(trustStatus.charAt(0));
+ var validity=EnigGetTrustLabel(uidValidityStatus.charAt(0));
if (!uidValid) {
userCol.setAttribute("properties", "enigKeyInactive");
-trustCol.setAttribute("properties", "enigKeyInactive");
+uidValidityCol.setAttribute("properties", "enigKeyInactive");
expCol.setAttribute("properties", "enigKeyInactive");
keyCol.setAttribute("properties", "enigKeyInactive");
-trust=EnigGetString("keyTrust.untrusted");
+validity=EnigGetString("keyTrust.untrusted");
}
- if (!userObj.subkeyOK && KEY_NOT_VALID.indexOf(trustStatus.charAt(0))<0) {
-trust=EnigGetString("keyValid.noSubkey");
+ if (!userObj.subkeyOK &&
KEY_NOT_VALID.indexOf(uidValidityStatus.charAt(0))<0) {
+validity=EnigGetString("keyValid.noSubkey");
}
if (((userObj.keyTrust.length>0) &&
(KEY_NOT_VALID.indexOf(userObj.keyTrust.charAt(0))>=0)) ||
(!userObj.subkeyOK) ||
((!gAlwaysTrust) && ("mfu".indexOf(userObj.keyTrust.charAt(0))<0)) ||
- ((!gAlwaysTrust) && trustStatus.length>0 &&
-("o-qn".indexOf(trustStatus.charAt(0))>=0))) {
+ ((!gAlwaysTrust) && uidValidityStatus.length>0 &&
+("o-qn".indexOf(uidValidityStatus.charAt(0))>=0))) {
userCol.setAttribute("properties", "enigKeyInactive");
-trustCol.setAttribute("properties", "enigKeyInactive");
+uidValidityCol.setAttribute("properties", "enigKeyInactive");
expCol.setAttribute("properties", "enigKeyInactive");
keyCol.setAttribute("properties", "enigKeyInactive");
if (!gAllowExpired && activeState>=0) activeState=2;
}
EnigSetActive(selectCol, activeState);
- trustCol.setAttribute("label", trust);
+ uidValidityCol.setAttribute("label", validity);
var userRow=document.createElement("treerow");
userRow.appendChild(selectCol);
userRow.appendChild(userCol);
- userRow.appendChild(trustCol);
+ userRow.appendChild(uidValidityCol);
userRow.appendChild(expCol);
userRow.appendChild(keyCol);
var treeItem=document.createElement("treeitem");
@@ -676,7 +676,7 @@ function enigmailUserSelCallback(event) {
if ((event.detail == 1) && (col.value.id != "selectionCol"))
return; // single clicks are only relvant for the selection column
-if ((event.detail == 2) &&
("selectionCol,enigUserNameCol,trustCol,expCol,keyCol".indexOf(col.value.id) <
0))
+if ((event.detail == 2) &&
("selectionCol,enigUserNameCol,uidValidityCol,expCol,keyCol".indexOf(col.value.id)
< 0))
return;
event.stopPropagation();
diff --git a/ui/content/enigmailUserSelection.xul
b/ui/content/eni
[Enigmail] [PATCH 3/4] Fix english grammar
--- ui/locale/en-US/enigmail.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ui/locale/en-US/enigmail.properties b/ui/locale/en-US/enigmail.properties index 74021fa..ea5141a 100644 --- a/ui/locale/en-US/enigmail.properties +++ b/ui/locale/en-US/enigmail.properties @@ -287,7 +287,7 @@ selKeyExpired=expired %S createdHeader=Created keyInvalid=INVALID KEY keyDisabled=DISABLED KEY -atLeastOneKey=No key selected! You have to select at least one key for accepting this dialog +atLeastOneKey=No key selected! You have to select at least one key to accept this dialog fewerKeysThanRecipients=You have selected a smaller number of keys than recipients. Are you sure that the list of keys to encrypt is complete? userSel.button.goBack=Select more Keys userSel.secretKeySel.title=Select a Secret OpenPGP Key to Sign Your Messages -- 1.8.5.1 ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] [PATCH 2/2] add subprocess support for GNU/kFreeBSD (debian)
This patch records the library name and constants expected for debian
GNU/kFreeBSD. Without this line, enigmail 1.6 on that platform
fails with:
[ERROR] enigmail.js: Enigmail.setAgentPath: subprocess.call failed with
'TypeError: platformDefaults[gXulRuntime.OS.toLowerCase(...)] is undefined'
---
ipc/modules/subprocess.jsm | 1 +
1 file changed, 1 insertion(+)
diff --git a/ipc/modules/subprocess.jsm b/ipc/modules/subprocess.jsm
index 7b3ccd6..3de6ccc 100644
--- a/ipc/modules/subprocess.jsm
+++ b/ipc/modules/subprocess.jsm
@@ -333,6 +333,7 @@ function getPlatformValue(valueType) {
'darwin': [ 'libc.dylib', 0x04 , ctypes.uint64_t , 8 ],
'linux': [ 'libc.so.6',2024 , ctypes.unsigned_long, 7 ],
'freebsd': [ 'libc.so.7',0x04 , ctypes.int64_t , 8 ],
+'gnu/kfreebsd': [ 'libc.so.0.1', 0x04 , ctypes.int64_t , 8 ],
'openbsd': [ 'libc.so.61.0', 0x04 , ctypes.int64_t , 8 ],
'sunos': [ 'libc.so', 0x80 , ctypes.unsigned_long, 5 ]
};
--
1.8.4.2
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] [PATCH 1/2] deal with XPCOM_ABI names with slash (like "GNU/kFreeBSD")
Without this patch, the sed expressions in genxpi get tripped up when
they encounter an XPCOM_ABI with a slash in it.
---
genxpi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/genxpi b/genxpi
index eb484fd..0d7608f 100755
--- a/genxpi
+++ b/genxpi
@@ -63,8 +63,9 @@ if [ "$xpcomAbi" = "" ] ; then
xpcomAbi="unknown"
fi
platform=${osArch}_${xpcomAbi}
+escplatform="$(printf "%s" "${platform}" | sed 's_/_\\/_g')"
# Pepare install.rdf
-sed 's//'${platform}'<\/em:targetPlatform>/' <
${srcDir}/package/install.rdf > ${targetDir}/install.rdf
+sed 's//'${escplatform}'<\/em:targetPlatform>/' <
${srcDir}/package/install.rdf > ${targetDir}/install.rdf
enigmimeDll=${libPrefix}enigmime${dllSuffix}
@@ -82,7 +83,7 @@
spDllFile=platform/${platform}/lib/${libPrefix}subprocess-${xpcomAbi}${dllSuffix
touch ${targetDir}/chrome.manifest
cp ${targetDir}/chrome.manifest ${targetDir}/chrome.manifest.save
cat ${srcDir}/package/chrome.manifest | \
-sed 's/##ENIGMIMEDLL-PLACEHOLDER##/binary-component
platform\/'${platform}'\/components\/'`basename ${enigDllFile}`'
ABI='${platform}'/' \
+sed 's/##ENIGMIMEDLL-PLACEHOLDER##/binary-component
platform\/'${escplatform}'\/components\/'`basename ${enigDllFile}`'
ABI='${escplatform}'/' \
> ${targetDir}/chrome.manifest
# Prepare languages other than en-US
--
1.8.4.2
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] debugging failed verification
On 11/12/2013 02:19 PM, ernie wrote: > I have been following this thread for some time. That's interesting, because i just started this thread a few hours ago! > Out of curiosity, are these problems win a flavor of Widows or Linux? I don't use Windows, so i don't know if these are problems on Windows. I'm seeing them (and am trying to debug them, which is the point of this thread) on a GNU/Linux platform. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] debugging failed verification
i'm trying to use the standard enigmail debugging capability to figure out why a message is failing verification in enigmail. The message is clearsigned PGP/MIME, and it verifes correctly in another MUA (notmuch, using libgmime). Other clearsigned PGP/MIME messages verify correctly. When i enable debugging, i'm hoping to get the post-processed data from the MIME info in eniginp.txt. however, because enigmail invokes gpg twice (once for the verification and once for the user IDs to show in the verification pane), the eniginp.txt i'm interested in (from the verification) is getting overwritten by the second command (the call to show the user IDs). is there a standard way to work around this when debugging? how should i try to get the processed text of the message so i can compare it to better-diagnose the MIME handling? --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] [PATCH 2/2] .xpi generation should fail if components are missing
On 11/12/2013 12:27 PM, Patrick Brunschwig wrote:
> This patch won't work for Thunderbird 19 and newer, as the referenced
> ${enigDllFile} (line 153) is only generated on Gecko version <= 18.
> Thus the files would not match.
this seems like something that genxpi should know about, no? If it
knows that it's being built against TB 18 or earlier, it could set
${enigDLLFile} to the empty string. does that make sense?
--dkg
signature.asc
Description: OpenPGP digital signature
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] C99 adoption
On 11/11/2013 05:43 PM, Michael Norrish wrote: > As for //, compilers have had this forever given that it's been in C++ > forever. yes, of course all modern compilers have this option. however, there's no reason for gratuitous incompatibility against older compilers or for people who for whatever reason don't want to enable --std=c99 behavior. The original patch posted causes no functional change in the code, it's just a simple style cleanup. I did not intend this to be controversial in any way! --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] [PATCH v2] avoid warning: variable 'rv' set but not used [-Wunused-but-set-variable]
Sorry for the earlier version, which had not been tested properly.
hopefully this one makes more sense.
This patch allows the build to proceed cleanly when using
-Wunused-but-set-variable
---
src/nsEnigMsgCompose.cpp | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/nsEnigMsgCompose.cpp b/src/nsEnigMsgCompose.cpp
index 2bc3f7a..bd4928a 100644
--- a/src/nsEnigMsgCompose.cpp
+++ b/src/nsEnigMsgCompose.cpp
@@ -77,10 +77,9 @@ nsEnigMsgCompose::nsEnigMsgCompose()
nsEnigMsgCompose::~nsEnigMsgCompose()
{
- nsresult rv;
#ifdef FORCE_PR_LOG
nsCOMPtr myThread;
- rv = ENIG_GET_THREAD(myThread);
+ ENIG_GET_THREAD(myThread);
DEBUG_LOG(("nsEnigMsgCompose:: > DTOR(%p): myThread=%p\n",
this, myThread.get()));
#endif
--
1.8.4.2
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] [PATCH] avoid warning: variable 'rv' set but not used [-Wunused-but-set-variable]
This patch allows the build to proceed cleanly when using
-Wunused-but-set-variable and without FORCE_PR_LOG
---
src/nsEnigMsgCompose.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nsEnigMsgCompose.cpp b/src/nsEnigMsgCompose.cpp
index 2bc3f7a..91ca07e 100644
--- a/src/nsEnigMsgCompose.cpp
+++ b/src/nsEnigMsgCompose.cpp
@@ -77,8 +77,8 @@ nsEnigMsgCompose::nsEnigMsgCompose()
nsEnigMsgCompose::~nsEnigMsgCompose()
{
- nsresult rv;
#ifdef FORCE_PR_LOG
+ nsresult rv;
nsCOMPtr myThread;
rv = ENIG_GET_THREAD(myThread);
DEBUG_LOG(("nsEnigMsgCompose:: > DTOR(%p): myThread=%p\n",
--
1.8.4.2
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] please tag 1.6 release in upstream git
hi there enigmail folks! It looks to me like the released enigmail-1.6.tar.gz is drawn from commit id a16b43c68c9a829034f44082c392e5f9fb42e864, but that commit is not explicitly tagged (or maybe it's tagged, but the tag hasn't been pushed to git://git.code.sf.net/p/enigmail/source). Could someone publish a signed tag for enigmail 1.6 in the git repository? Thanks, --dkg pgpL7QfiG_pKn.pgp Description: PGP signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] enigmail picks invalid key ID
On 11/11/2013 02:16 PM, Ludwig Hügelschäfer wrote: > On 11.11.13 20:03, Kai Poeritz wrote: > >> Why does Enigmail pick this old "038D1C4D" ID? How can I make it use the >> right ID? > > While admitting that the observed behaviour is not good, please keep to > the recommendation: Set the key-Id to be used explicitly in account > settings, OpenPGP section instead of relying on the email address to > address the right key. fwiw, i believe enigmail is just relying on gpg to select "the right key" here, and gpg is failing to do the right thing. In particular, gpg seems to select a key for a given User ID based on the first match in a linear scan of its public keyring. This is suboptimal behavior for a variety of reasons, but it doesn't look like the gnupg folks plan to fix it until the (unknown) future release of the 2.1 version. One way to work around this is to remove the old key from your gpg keyring entirely. another way is to "bump the old key to the end" so gpg finds the newer key shows up first in its linear scan. that'd look something like: gpg --armor --export $OLDKEYID > oldkey.asc gpg --delete-key $OLDKEYID gpg --import < oldkey.asc hth, --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] [PATCH 2/2] .xpi generation should fail if components are missing
Without this change, zip would happily carry on even if some elements
are missing due to other undetected failures in the build process.
It's better to catch errors in the .xpi generation at build time,
rather than at install or runtime.
---
genxpi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/genxpi b/genxpi
index eb484fd..d67ee3a 100755
--- a/genxpi
+++ b/genxpi
@@ -128,7 +128,7 @@ fi
echo "Creating ${xpiFile} file"
-zip ${xpiFile} \
+zip --must-match ${xpiFile} \
components/${xpiModule}.xpt \
components/${xpiModule}.js \
components/enigprefs-service.js \
--
1.8.4.2
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] [PATCH 1/2] Use standard C comments in subprocess.c
Including this patch makes it possible to build subprocess.c in a
compiler with strict rules about C comments.
---
ipc/src/subprocess.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/ipc/src/subprocess.c b/ipc/src/subprocess.c
index 47ad18c..0019e7c 100644
--- a/ipc/src/subprocess.c
+++ b/ipc/src/subprocess.c
@@ -8,12 +8,12 @@
void closeOtherFds(int fdIn, int fdOut, int fdErr) {
- int maxFD = 256; // arbitrary max
+ int maxFD = 256; /* arbitrary max */
int i;
struct rlimit rl;
if (getrlimit(RLIMIT_NOFILE, &rl) == 0) {
- if (rl.rlim_cur < 99) // ignore too high numbers
+ if (rl.rlim_cur < 99) /* ignore too high numbers */
maxFD = rl.rlim_cur;
}
@@ -37,7 +37,7 @@ pid_t launchProcess(const char *path, char *const argv[],
char *const envp[],
pid = fork();
if (pid == 0) {
-// child
+/* child */
if (workdir) {
if (chdir(workdir) < 0) {
_exit(126);
@@ -60,6 +60,6 @@ pid_t launchProcess(const char *path, char *const argv[],
char *const envp[],
_exit(1);
}
- // parent
+ /* parent */
return pid;
}
--
1.8.4.2
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Keys do not show up in per-recipient rules
On 10/20/2013 08:34 AM, Martin Braun wrote: > I have some keys in my keyring which I can access and edit through > enigmails "Key Management" tool as well as any other GPG program. I'm > sure they're valid keys and in the keyring. > The keys are not expired, and I have also tried giving them a trust > level assigning "trust" (aka "ownertrust") to a key means that you are willing to believe identity certifications made by that key. it does not indicate whether you think the key actually belongs to a given person. in the context you're asking about (whether enigmail is willing to encrypt mail sent to that key), this is not a relevant operation. it is also a risky operation (people to whom you have assigned full ownertrust can effectively man-in-the-middle your communications by having you encrypt them to the wrong keys. > Now, when I try to actually use them from enigmail, they won't show up. > When I try to use them from the per-recipient rules, they simply don't > show up in the list. It's as if "Key Management" and the per-recipient > key selection dialog have different keyrings -- but don't ask me where > the latter gets its keys from; it seems like a random subset of my keys. i'm assuming you're talking about the dialog box that opens when you choose "select keys" from the "new" or "edit" sub-dialog of the "per-recipient rules" workflow. is that correct? what version of thunderbird are you using? what version of enigmail? --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Enigmail refuses to use unsigned key for encryption
Hi Ralf-- On 10/15/2013 05:14 PM, Ralf Jung wrote: > why does Enigmail refuse to use an unsigned key for encryption? A friend > of mine recently contacted me via encrypted mail, and while I was able > to get her key from a keyserver, I couldn't get a signature for it, so I > decided to do that later but reply now. However, after hitting "Send", > when Enigmail asked me which key to use for encryption, her key was > marked red and I wasn't able to encrypt the mail - so I had the choice > of signing a key I did not verify at all, or sending an unencrypted > email. Why is that? enigmail relies on gpg for the association between keys and e-mail addresses. gpg understands (correctly) that the keys in your keyring are effectively populated over the network (e.g. keyserver fetches) and shouldn't be considered validly-bound to their claimed user IDs without some other indication that the user does actually believe these keys to belong to the indicated user. This is a good thing -- it makes it so that if you import a key from someone else who happens to claim to have your friend's e-mail address, enigmail won't accidentally encrypt your messages to that other person. In the situation you describe, where you suspect that a given key belongs to your friend, and you are willing to use it for now, i would use a time-limited (a few months perhaps?) local (a.k.a. "non-exportable") signature on just the User ID i plan to correspond with, and then do my best to confirm her key's fingerprint securely within the time limit, so i could go ahead and do a regular keysigning. hope this helps, --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Bad signature
On 10/09/2013 05:47 PM, Bryant Evans wrote: > Not sure my message earlier went through. Trying again. I am using > PGP/MIME as suggested. both of these PGP/MIME messages appear to have a valid signature from Key fingerprint: 3FDD CDC3 F146 3309 7FEE F699 19C1 9D85 1C0B 95E5 So whatever problem you're running into appears to only manifest itself when sending clearsigned inline PGP. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Bad signature
On 10/09/2013 07:01 AM, Klearchos-Angelos Gkountras wrote: > have you upload your public key to pgp server ? try pgp.mit.edu please do not recommend pgp.mit.edu [0]. If you're going to recommend keyservers to the general public, you should recommend the high-availability pool [1] at this point: ha.pool.sks-keyservers.net > On 10/09/2013 01:56 PM, Bryant Evans wrote: > >> Ok, I replied to the list to answer and question and my signature >> came back bad. I sent myself a message, encrypted, and it came in >> fine. What am I missing? it sounds like you sent two messages: a) to the list, inline-PGP signed (i think you're talking about Message-ID: <52552f34.2060...@bryantevans.com>) b) to yourself, encrypted Note that encryption ≠ signing. Was (b) itself signed? (a) appears to be generated by enigmail 1.6 with gnupg 2.0.19 and thunderbird 24 on windows. I tried to verify it with key 0x3FDDCDC3F14633097FEEF69919C19D851C0B95E5 and also got BAD signature. It looks to me like all of your inline-PGP-signed messages to this list have unverifiable signatures. can you try sending a PGP/MIME-signed message to the list instead? when composing a message, from the "OpenPGP" menu, ensure that "Use PGP/MIME for this message" is checked. Regards, --dkg [0] https://we.riseup.net/debian/openpgp-best-practices#dont-use-pgp-mit-edu [1] https://sks-keyservers.net/overview-of-pools.php signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] PGP signature brakes text signature?
On 09/20/2013 05:30 AM, Antonio Kless wrote: > I use Thunderbird 17.0.7 with Enigmail 1.5.2 (20130703-1322). > > I have text signature configured for my email account into > Thunderbird, it inserts signature automatically every time I send a > message, by adding "--" and signature text after message's text (as in > this current email message you reading). > > When I sign message with PGP by Enigmail, the "--" before text > signature changes to "- --", this is annoying behavior, and I > searching way to solve them. This is due to the "dash-escaping" required of cleartext inline PGP signatures: https://tools.ietf.org/html/rfc4880#section-7.1 You could avoid it by switching to PGP/MIME instead of using inline PGP. In thunderbird+enigmail, i think you can choose PGP/MIME by default for message composition in "Acocunt Settings" » "OpenPGP Security" » "Use PGP/MIME by default". hth, --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] help understanding the build process?
Hi Patrick and other enigmail folks-- I'm trying to better understand the enigmail build process so that i can keep it up to date within debian. I see that in the changes to 1.5.2 you've updated the source to use the new mozilla build system (e.g. commit 283b077aa), but 1.5.2 is intended to be used with thunderbird 17.0, which does not have the updated build system. Does this mean that 1.5.2 is built against upstream's beta sources (prereleases of TB 24), but they effectively retain compatibility with the older (17.0) "stable" releases? Or was 1.5.2 built against the TB 17 sources that were somehow integrated into the new build system? I'm a little leery of trying to ship cross-built binaries so it would be useful to me to know how you're doing the build for the binary packages shipped on enigmail.net. I'm still struggling with complexities of building enigmail from source, so i might also be misusing the terms above. I would welcome any edifying corrections or clarifications :) Thanks as always for your work on enigmail. It is a great tool to have. Regards, --dkg pgpmKYHi4l2KP.pgp Description: PGP signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Do I have to create a new revocation certificate if I change my passphrase?
On 09/13/2013 08:10 AM, Bob Williams wrote: > Should I create a new revocation certificate if I change my > passphrase? Or is the passphrase only 'local' to my secring.gpg? Your old revocation certificate will still work. Both the revocation certificate and the public part of your key can be evaluated together with no other information. your passphrase belongs only to the secret part of your key, so it is not relevant to the validity or interpretation of the revocation certificate. make sense? --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] enigmail verification problem with signed message/rfc822 subparts
[about Eduard Christian Dumitrescu 's proposal to only display the signed parts of a multipart message that validates successfully to avoid spoofed headers/footers] On Thu 2013-05-30 06:10:37 -0400, Ludwig Hügelschäfer wrote: > On 30.05.13 10:47, Patrick Brunschwig wrote: >> >> This is only partially feasible. It will certainly work for inline >> PGP, but I can't say anything about PGP/MIME. The next major version >> of TB will most likely come with a new MIME processing library, and I >> know nothing about it except that it should land on trunk more or >> less soon. Given that I don't know what changes this will impose to >> Enigmail, I certainly won't do anything for the moment. > > Full ack. This can only be a post Thunderbird 24 task given the limited > resources we have. We'll see which TB code canges come (and probably > need adaptations within Enigmail) until end of june when Thunderbird 24 > enters aurora channel. There are chances that fixes for the broken > things will even take longer. Have you had any chance to look at the TB MIME processing code in the upcoming TB 24 to see if this approach is feasible? Regards, --dkg pgpDk7FJNDI5C.pgp Description: PGP signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Enigmail Wizard does not find all of my PGP keys
On 09/09/2013 03:29 PM, Paul Johnson wrote: > I'm using Icedove (Debian's Thunderbird) version 17.0.8 and Enigmail > > I've got several keys for different purposes. > > $ gpg --list-keys | grep paul > /home/pauljohn/.gnupg/pubring.gpg > uid Paul E. Johnson (PGP Key 20101104) > uid Paul E. Johnson (2011-10-06 KU Rocks) > uid Paul Johnson (Binary Package Signing Key) > > uid Paul E. Johnson (Debian Packaging) > your pipeline only lists user IDs, not keys, so it's difficult to tell whether there are separate keys involved. also, it lists public keys, not secret keys. maybe you don't actually have the secret key material available? > I want to use the top one, "(PGP Key 20101104)" to sign emails, but the Wizard > only finds 2, the ones named (2011-10-06 KU Rocks) and (Debian Packaging). if that's the one on the public keyservers with that comment, try: gpg --list-secret-keys 0xE1F06E9541EB6004 does it show up there? --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Development: Marking a message as "to be encrypted" before it is created
On 08/18/2013 06:41 AM, Max Maass wrote: > As I do not have enough experience with the Enigmail Source yet, I > have no idea where even to begin to look for them. So I would be very > grateful for an idea on what to do next. If we want to keep the ML out > of this (I don't know if this is interesting or annoying for everyone > else on [Enigmail]), we can take this to personal eMail as well, if > you want. I can't speak for the rest of the mailing list, but i'm quite happy to see this discussion on-list, and in the archives. I find it useful, even though i'm just lurking in this conversation. Thanks for your work on extending enigmail to cover this use case more smoothly. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] [Pkg-mozext-maintainers] Enigmail in Debian
On 07/15/2013 04:34 PM, Ximin Luo wrote: > For xul-ext-gnome-keyring, I am building the extension twice, against both > xulrunner-dev *and* icedove-dev, then packaging both binaries into the same > XUL extension and using the appId to tell XPCOM to conditionally load the > correct one. Have a look at debian/rules for source, although I don't know if > the same strategy would be applicable to enigmail. I'm also not sure which > version of the xulrunner lib the Debian iceape uses. > > http://packages.debian.org/sid/xul-ext-gnome-keyring > https://github.com/infinity0/mozilla-gnome-keyring/tree/debian This is a neat approach, but my understanding of enigmail is that the the issue is not just building against different -dev environments; there are actually changes in enigmail source between the different versions that are aligned to the behavior of the corresponding MUA versions. So i don't think just building the same source package twice against different dev environments will do the trick :( --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Enigmail in Debian
On 07/15/2013 02:37 PM, Klearchos-Angelos Gkountras wrote: > I am using Debian Sid and icedove as my personal email programm and I > didn't install enigmail via repos but with icedove's add-ons manager . > Please describe in which branch of debian is the problem ;) This goes against the general recommendations of the enigmail team -- their suggestion is that you install icedove/thunderbird and enigmail from the same source; if you use your distro's version of the MUA, use your distro's version of the plugin; if you use the "upstream" binary distribution of the MUA, use the "upstream" binary distribution of the plugin. > don't forget that debian has three branches > branchcode name > > stable| wheezy > testing | jessie > unstable | sid > Andy's concern is about iceape (seamonkey) which is version 2.7.12-1 in all three active suites of debian (wheezy, jessie, and sid). icedove is now at version 17.0.7 in wheezy (thanks to a security update), and enigmail was updated to match the icedove version. However, iceape has not been similarly updated. There appears to be less developer time spent on iceape than on the other mozilla variants :( So Andy is right that there are versioning issues with enigmail in wheezy if you try to use it with iceape. As one of the members of the debian project who is trying to keep enigmail functional in debian, i'm not sure what the answer is. We would love to continue to support enigmail for iceape as well as icedove, but i'm not sure what the right thing to do is. if we're using the system-installed locations, i don't see how we can have the two versions of enigmail co-installable. I'm cc'ing the mozilla extension packaging team on the e-mail to see if anyone has any suggestions for resolving this conflict in a healthy way. Sorry to not have any more productive answers myself, --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
