Bug#891882: (no subject)
Done. See commit 1d32b9b2c291b8570a9985016d445fe16d72ad7b on master and enigmail-2.0 branch This should make it simple for distributions and companies that do not want to download pEp automagically.
Bug#891882: (no subject)
I will add the following default preference in Enigmail:
pref("extensions.enigmail.pEpAutoDownload", true);
If the value is set to false, then Enigmail will not attempt to download
pEp at all.
Bug#867542: [Enigmail] 'invalid language tag' since 30c1fe69 [was: Re: Bug#867542: enigmail: can't decrypt messages in thunderbird]
On 12.07.17 02:55, Daniel Kahn Gillmor wrote:
> Control: severity 867542 normal
>
> Hi Jörg--
>
> Over in https://bugs.debian.org/867542, you wrote:
>
>> decryption of messages in thunderbird fails.
>
> how does it fail? does it hang? show you an error message?
>
>> The log of enigmail shows this:
>>
>> --- %< ---
>> 2017-07-07 08:34:46.501 [DEBUG] errorHandling.jsm: parseErrorOutputWith:
>> statusFlags = 0020
>> 2017-07-07 08:34:46.501 [DEBUG] errorHandling.jsm: parseErrorOutputWith:
>> return
>> with c.errorMsg =
>> 2017-07-07 08:34:46.501 [DEBUG] execution.jsm: EnigmailExecution.fixExitCode:
>> agentType: gpg exitCode: 0 statusFlags undefined
>> 2017-07-07 08:34:46.502 [CONSOLE]
>> 2017-07-07 08:34:46.502 [DEBUG] keyRing.jsm: createAndSortKeyList()
>> 2017-07-07 08:34:46.504 [ERROR] enigmailMessengerOverlay.js:
>> messageDecryptCb:
>> caught exception: RangeError
>> Message: 'invalid language tag: en-US.UTF-8'
>> File:resource://enigmail/time.jsm
>> Line:48
>> Stack: EnigmailTime.getDateTime@resource://enigmail/time.jsm:48:14
>> KeyObject@resource://enigmail/keyRing.jsm:1607:19
>> appendKeyItems@resource://enigmail/keyRing.jsm:1436:20
>> createKeyObjects@resource://enigmail/keyRing.jsm:1411:3
>> createAndSortKeyList@resource://enigmail/keyRing.jsm:1560:3
>> loadKeyList@resource://enigmail/keyRing.jsm:1283:3
>> EnigmailKeyRing.getAllKeys@resource://enigmail/keyRing.jsm:151:7
>> EnigmailKeyRing.getKeyById@resource://enigmail/keyRing.jsm:222:7
>> EnigmailDecryption.decryptMessageEnd@resource://enigmail/decryption.jsm:348:26
>> EnigmailDecryption.decryptMessage@resource://enigmail/decryption.jsm:553:20
>> Enigmail.msg.messageParseCallback@chrome://enigmail/content/enigmailMessengerOverlay.js:1005:19
>> Enigmail.msg.messageParse@chrome://enigmail/content/enigmailMessengerOverlay.js:926:5
>> Enigmail.msg.messageDecryptCb@chrome://enigmail/content/enigmailMessengerOverlay.js:764:9
>> _f@chrome://enigmail/content/enigmailMessengerOverlay.js:555:9
>> callbackWrapper@resource://enigmail/timer.jsm:38:9
>> --- >% ---
>
> thanks for the logs. Was it repeatable reliably with 1.9.8-1 ? Are you
> able to get this to repeat with 1.9.8.1-1 (the version i uploaded to
> unstable today)?
>
>> Something seems odd with the language tag "en-US.UTF-8".
>>
>> The command "locale -a" shows on this system among others "en_US.utf8".
>
> I am used to seeing en_US.UTF-8 for LANG, but not en-US.UTF-8. Are you
> setting NSILOCALE_TIME anywhere in your environment?
>
>> For the moment I will revert back to the last working version 2:1.9.7-2.
>
> The line you're getting an error on was definitely changed between 1.9.7
> and 1.9.8 (it was changed in 30c1fe69a7c62007f925d760efc832884aed4412,
> which overhauls the time calculations).
>
> Maybe upstream (cc'ed here) can shed some light on this?
We had to change this for Thunderbird 52 due to the following Mozilla
bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1367672
The correct locale format in Thunderbird is xx-yy (not xx_yy). However,
Thunderbird seems to be unable to cope with additional parameters in the
locale like ".UTF-8".
I would expect that the following patch fixes the issue.
-Patrick
--- a/package/time.jsm
+++ b/package/time.jsm
@@ -52,7 +52,10 @@ const EnigmailTime = {
options.minute = DATE_2DIGIT;
}
- return new
Intl.DateTimeFormat(appLocale.getCategory("NSILOCALE_TIME"),
options).format(dat);
+ let useLocale = appLocale.getCategory("NSILOCALE_TIME").substr(0, 5);
+ useLocale = useLocale.replace(/_/g, "-");
+
+ return new Intl.DateTimeFormat(useLocale, options).format(dat);
}
else {
return "";
Bug#403396: [Enigmail] Bug#403396: enigmail: security issue: attachments may be not encrypted
Alexander Sack wrote: Hi ... I couldn't reproduce this debian bug report ... however before I miss something important, maybe you want to take a look at the code if there might be a case where attachments might not get encrypted ... For more info, please read http://bugs.debian.org/403396. BTS, Maybe keep bug email ([EMAIL PROTECTED]) CCed too. Thanks a lot, I can't reproduce the bug neither. However, I doubt that the reporter really did what he wrote. He reports that his prefs.js file contains the following line: user_pref(extensions.enigmail.encryptAttachments, 0); But this means: encrypt the message body, but not the attachments. Thus I'm not surprised about the result. -Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310328: Bug #310328,Upgrading gnupg with open enigmail causes serious problem
The lock files are normal and required. If enigmail opens several gpg processes you might get into a deadlock situation. From you rlisting it seems that 2 processes are running. Please provide more information for example by attaching strace to the running gpg processes. Enigmail (or rather Mozilla) has some internal problems in handling several gpg prcesses correctly, so wherever possible I try to prevent this. I have tried to reproduce the problem with the files provided (on a Windows system though; I don't have a Linux system available), but I could not find anything to be wrong. It's true that recalculating the trustdb takes a while, but Enigmail just waits happily until gpg is ready with calculating. -Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310328: Bug #310328,Upgrading gnupg with open enigmail causes serious problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roberto C. Sanchez wrote: But why would cancelling the key retrieval midstream leave gpg like it did? When I reproduced the bug the second time, I initiated a key retrieval (from pgp.mit.edu, if it makes a difference) and after about 60 seconds of waiting, I cancelled it. That was what caused the locks and tmp files to be left behind. Could that be indicative of a gpg bug? OK, now we're getting closer :-) This /should/ not happen (i.e. gpg should be terminated by Enigmail), but maybe this didn't happen. Did you search for a key using the Enigmail key manager, or did you try to import a key when reading a message? And what precise version of Enigmail did you use? - -Patrick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCkycl2KgHx8zsInsRAhyuAJ9vK3cF+7byAPZm3MFZGOGIsEAAsQCgkRZF LUHV31/KAlh30DliuedVgwk= =g1ja -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310328: Bug #310328,Upgrading gnupg with open enigmail causes serious problem
Roberto C. Sanchez wrote: I was trying to import a key while reading a mail message. I cancelled from the progress dialog that shows while the key import is in progress. OK, I just come from modifying this over the weekend. I believe this should be solved in the next version. -Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
