Every first time in a while when I send a signed e-mail, it takes about 8 seconds until the passphrase dialog appears and I can enter my passphrase. Other times it's fast and the dialog appears immediately. I haven't found a scheme behind it. This first happened on my previous Windows setup. Since that also had other issues, I re-installed Windows and only copied my Thunderbird profile, but that didn't change anything.
What could be the cause for this long delay?
Using latest Thunderbird stable and Enigmail on Windows 7 SP1 x64. With Gpg4win, in case that matters.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
During the first launch of GnuPG, when Enigmail detects the GnuPG
version number, GnuPG detects if gpg-agent is running, and if not it
will start gpg-agent. This is what causes the delay. There is not much
you can do about this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you invoke gpg after a longer pause (days), it scans the keyring in order to determine outdated keys and reconstructing its trust database. This can take seconds or even longer if you have a large (public) keyring, i.e. many stored public keys.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can't it do that asynchronously? After all the user is sitting here and waiting for some action. I'm not interested in internal cleanup right now, that can happen another time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, this can't be asynchronously -- you need to enter your passphrase and this is done via gpg-agent. But you ask at the wrong place. Enigmail is only a front-end to. GnuPG and the related tools are not developed by Enigmail.
In theory, you could start gpg-agent when you log on to your computer, such that it is already present. But I'm not sure how this would be done on Windows.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, I'll keep an eye on whether that process is currently running before sending e-mails. Starting it when logging in sounds like a good work-around, I could give it a try then. Thanks for the ideas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Every first time in a while when I send a signed e-mail, it takes about 8 seconds until the passphrase dialog appears and I can enter my passphrase. Other times it's fast and the dialog appears immediately. I haven't found a scheme behind it. This first happened on my previous Windows setup. Since that also had other issues, I re-installed Windows and only copied my Thunderbird profile, but that didn't change anything.
What could be the cause for this long delay?
Using latest Thunderbird stable and Enigmail on Windows 7 SP1 x64. With Gpg4win, in case that matters.
During the first launch of GnuPG, when Enigmail detects the GnuPG
version number, GnuPG detects if gpg-agent is running, and if not it
will start gpg-agent. This is what causes the delay. There is not much
you can do about this.
If you invoke gpg after a longer pause (days), it scans the keyring in order to determine outdated keys and reconstructing its trust database. This can take seconds or even longer if you have a large (public) keyring, i.e. many stored public keys.
Can't it do that asynchronously? After all the user is sitting here and waiting for some action. I'm not interested in internal cleanup right now, that can happen another time.
No, this can't be asynchronously -- you need to enter your passphrase and this is done via gpg-agent. But you ask at the wrong place. Enigmail is only a front-end to. GnuPG and the related tools are not developed by Enigmail.
In theory, you could start gpg-agent when you log on to your computer, such that it is already present. But I'm not sure how this would be done on Windows.
Okay, I'll keep an eye on whether that process is currently running before sending e-mails. Starting it when logging in sounds like a good work-around, I could give it a try then. Thanks for the ideas.
Thanks for the ideas too. I observe that the process is still running before sending the emails.