Enigmail still broken on Linux: cannot generate key
OpenPGP addon for Mozilla Thunderbird
Brought to you by:
pbrunschwig
Menu
▾
▴
#658 Enigmail still broken on Linux: cannot generate key
Pressing the 'generate key' button does nothing. Other buttons in the same window work. I suppose it is possible that Engimal is generating a key but not showing in any way that it is. But, on Windows, a confirmation prompt is displayed - which I don't see in Linux.
'Import from file' doesn't work on Linux either!
Can you please attach a debugging log file as explained here: https://www.enigmail.net/index.php/en/faq-en?view=topic&id=15 ?
Thanks for the reply.
I've now got it to work on Linux, but only by creating the key on Windows and somehow managing (I don't know quite how) to import the key on Linux.
I cannot find the log, or a way to create the log, that you request. The instructions on the page you linked say, 'Open the Enigmail Preferences panel (OpenPGP->Preferences)'; they neglect to say that the 'OpenPGP' item in question is under account settings (and, within that, under a particular mail account) and not in Thunderbird's general options. Worse: I cannot, anywhere, and on neither Windows nor Linux, find the option to generate or reveal a log file. I am using Engimail 1.9.6.1 (on both computers) on Thunderbird 45.5.1 (on Linux) and 50.0b3 (Windows).
depending on the version of Enigmail, the menu is called "Enigmail" or "OpenPGP" (in your case most likely Enigmail)
Patrick: the option is accessible via the main Firefox toolbar menu, and, subsequently, under 'debugging options'. None of that is mentioned on your webpage. So that page needs correcting.
Yes, I already corrected the website.
I cannot see any attempt to create a key in the log file. Can you please retry the key creation and then create a debug log file?
That may be because I reinstalled the extension to try to get it to work; I can't recall whether or not I did.
No, I am afraid not. Sorry. For, having got it working - after spending much time on it - I do not want to risk breaking it again. Perhaps you could try your end on an installation (Mint 18 Cinnamon x64, kernel 4.4.0-51-generic, Thunderbird 45.5.1) similar to mine.
I'm sorry, but my environment already consists of a Mac, a Windows 7, a Windows 10 and an Ubuntu system. I cannot install each and every Linux system that is available on the market. Key creation works fine for me on all these systems.
Aha. Well, you try it on a 'live USB'. I note also that someone else reported a problem creating keys on Linux (the person doesn't say with what distriubtion) and even came up with a fix.
So, as a summary, it is not possible for the moment to reproduce the issue you had. That's sad, but I can understand that you won't risk any breakage.
For the cited link: If the .gnupg directory beneath the users home is created with root permissions, this is surely not Enigmails fault, as Enigmail doesn't even know this directory, all cryptographic operations are done via GnuPG which administers this directory. So this is either done wrong by GnuPG or by the distribution.
Could we persuade you, after having obtained more confidence with your installation, retest key generation?
I don't know; I've got enough revoked keys as it is (if I am understanding how that works).
I will note the following. It seems non-trivial for a user to determine whether a problem should be ascribed and reported to (1) GnuPG or instead to (2) Enigmail; and that seems likely to get in the way of fixing bugs.
It is indeed not trivial to determine if a problem is due to Enigmail or GnuPG. However, my experience from the last 10 years is that about 80% of all problems are environment-specific (setup) issues and as such are not bugs that could be fixed in any way.
Or why do you think that Enigmail would need to fix a ~/.gnupg directory issue that is owned by root? Would other software do more than spit out "it doesn't work" if a directory is not writeable?
Thank you for your thoughts.
I don't know - I am a user more than a programmer. I note, though, that the report to which I linked seems to say that, in the case at issue, no error message of any kind appeared.
Hello again. I am back, because I had the need to generate a new key (on Linux - or at least I chose to do it on Linux, even though it did not work last time). It appears not to be working this time, but possibly the program is still doing the generation. It's hard to tell. Upon clicking 'generate' a dialogue box did appear, but, having dismissed the box by choosing an option, I see, still, this (see attachment).
Here's the current log. I note that when I try to close the window (the one I attached the screenshot of) a pop-up appears asking if I want to abort key generation. Even that message is unclear. Does it mean the generation is actually happening, or only that by closing the window I will be . . closing the key generation window?
I'm going to go and generate the key on Windows.
On Tue 2016-12-06 02:18:26 -0500, JN wrote:
I suspect that your linux system is having a hard time generating enough
entropy to supply GnuPG with what it tries to consume for key
generation.
have you followed the suggestion about doing things to add system
entropy, like typing randomly, wiggling the mouse, or performing unusual
disk access patterns?
it's possible that it works on windows because it doesn't grab as much
entropy from the system, or because windows returns "random" numbers
much more rapidly than /dev/random does.
Yes, I did try those things. It seems to me that on Linux the key creation does not even begin, for no progress bar appears. If, though, you think it is not clear whether or not the process had started (what did the logs reveal?) - or at least that it is very hard for the user to determine that - then there's one thing that needs changing right there.
The log is perfectly OK to me, there is no error and everything looks the way it should. That is, GnuPG has started to generate a key.
Well, then, and as I said: that should be made clear to the user. (Perhaps on other systems it is clear; yet, as I have tried to indicate, it is not clear on mine.)