Recent (?) problems with gpg

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Recent (?) problems with gpg

Jack
Hello all,

Another strange problem - not really Balsa's problem, but that's where  
I found it.

Today, I found I had a few messages which, when selected, simply froze  
Balsa for something like 30 seconds.  I finally noticed (if I just  
waited and didn't already click on three other things) that there was  
an error from gpg2, trying to fetch the key from pgp.mit.edu.  Manually  
invoking gpg2 from command line had the same delay and error message,  
thus I know the problem is not really in Balsa.

Lots of Googling led me to add the line "standard-resolver" to  
~/.gnupg/dirmngr.com, and then kill the currently running dirmngr  
process.  Although that particular key returned "no data", at least it  
now does so immediately, without the delay (timeout?)

Is this a known problem?  Is it something I should bring up with my  
distro, or directly with gnupg/dirmngr upstream?  All the posts I did  
find refered to older versions of gnupg, I'm now on 2.1.20.

Thanks for any suggestions.

Jack
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent (?) problems with gpg

Albrecht Dreß
Hi Jack:

Am 31.07.17 00:05 schrieb(en) Jack:
> Today, I found I had a few messages which, when selected, simply froze Balsa for something like 30 seconds.  I finally noticed (if I just waited and didn't already click on three other things) that there was an error from gpg2, trying to fetch the key from pgp.mit.edu.  Manually invoking gpg2 from command line had the same delay and error message, thus I know the problem is not really in Balsa.
>
> Lots of Googling led me to add the line "standard-resolver" to ~/.gnupg/dirmngr.com, and then kill the currently running dirmngr process.  Although that particular key returned "no data", at least it now does so immediately, without the delay (timeout?)
>
> Is this a known problem?  Is it something I should bring up with my distro, or directly with gnupg/dirmngr upstream?  All the posts I did find refered to older versions of gnupg, I'm now on 2.1.20.

I use an older GnuPG version (2.1.11), so I'm not sure if this is helpful for you...

Do you have the option “auto-key-retrieve” activated in your ~/.gnupg/gpg.conf file?  Quoting from the man page:

<snip>
auto-key-retrieve

This option enables the automatic retrieving of keys from a keyserver when verifying signatures made by keys that are not on the local keyring.

Note that this option makes a "web bug" like behavior possible.  Keyserver operators can see which keys you request, so by sending you a message signed by a brand new key (which you naturally will not have on your local keyring), the operator can tell both your IP address and the time when you verified the signature.
</snip>

This might explain the behaviour you observed.  In general I would recommend to disable this option, and to launch the key download from Balsa manually.  The latter is performed fully in background (in a separate thread), thus not blocking Balsa.  You have to re-check the message after a successful key download as to verify the signature, though.

Hope this helps,
Albrecht.
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent (?) problems with gpg

Jack
Hi Albrecht,

On 2017.08.02 06:48, Albrecht Dreß wrote:

> Hi Jack:
>
> Am 31.07.17 00:05 schrieb(en) Jack:
>> Today, I found I had a few messages which, when selected, simply  
>> froze Balsa for something like 30 seconds.  I finally noticed (if I  
>> just waited and didn't already click on three other things) that  
>> there was an error from gpg2, trying to fetch the key from  
>> pgp.mit.edu.  Manually invoking gpg2 from command line had the same  
>> delay and error message, thus I know the problem is not really in  
>> Balsa.
>>
>> Lots of Googling led me to add the line "standard-resolver" to  
>> ~/.gnupg/dirmngr.com, and then kill the currently running dirmngr  
>> process.  Although that particular key returned "no data", at least  
>> it now does so immediately, without the delay (timeout?)
>>
>> Is this a known problem?  Is it something I should bring up with my  
>> distro, or directly with gnupg/dirmngr upstream?  All the posts I  
>> did find refered to older versions of gnupg, I'm now on 2.1.20.
>
> I use an older GnuPG version (2.1.11), so I'm not sure if this is  
> helpful for you...
>
> Do you have the option “auto-key-retrieve” activated in your  
> ~/.gnupg/gpg.conf file?  Quoting from the man page:
>
> <snip>
> auto-key-retrieve
>
> This option enables the automatic retrieving of keys from a keyserver  
> when verifying signatures made by keys that are not on the local  
> keyring.
>
> Note that this option makes a "web bug" like behavior possible.  
> Keyserver operators can see which keys you request, so by sending you  
> a message signed by a brand new key (which you naturally will not  
> have on your local keyring), the operator can tell both your IP  
> address and the time when you verified the signature.
> </snip>
>
> This might explain the behaviour you observed.  In general I would  
> recommend to disable this option, and to launch the key download from  
> Balsa manually.  The latter is performed fully in background (in a  
> separate thread), thus not blocking Balsa.  You have to re-check the  
> message after a successful key download as to verify the signature,  
> though.
>
> Hope this helps,
> Albrecht.
Yes, it turns out I do have auto-key-retrieve enabled, and per your  
suggestion will disable it.   However, I assume I would get the same  
delay when manually retrieving (or trying to retrieve) the key  
manually.  My underlying question is whether the need to add  
"standard-resolver" to dirmngr.com indicates a bug anywhere or just a  
configuration issue that perhaps just should have been of higher  
visibility.  Gentoo just upgraded the gnupg version available, so once  
I do upgrade, I'll have to test by undoing that change.

Interesting note:  the "missing" key was for a developer on another  
list I'm on - he had set up a new key and then got interrupted before  
actually uploading it to the keyserver, so at least this issue prompted  
me to ask him, which prompted him to finish the upload, and also revoke  
his previous key.

Jack
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Recent (?) problems with gpg

Albrecht Dreß
Hi Jack:

Am 02.08.17 18:08 schrieb(en) Jack:
> Yes, it turns out I do have auto-key-retrieve enabled, and per your suggestion will disable it.   However, I assume I would get the same delay when manually retrieving (or trying to retrieve) the key manually.

Yes.  But as Balsa runs this in a separate thread (recent git version) or forks gpg (older versions), this does not block the interface.

> My underlying question is whether the need to add "standard-resolver" to dirmngr.com indicates a bug anywhere or just a configuration issue that perhaps just should have been of higher visibility.

Good question…  Actually, I /thought/ it was needed for S/MIME only.  However, the latest GnuPG manual says [1]

<snip>
Since version 2.1 of GnuPG, dirmngr takes care of accessing the OpenPGP keyservers. As with previous versions it is also used as a server for managing and downloading certificate revocation lists (CRLs) for X.509 certificates, downloading X.509 certificates, and providing access to OCSP providers. Dirmngr is invoked internally by gpg, gpgsm, or via the gpg-connect-agent tool.
</snip>

The docs simply say about the "standard-resolver" option:

<snip>
standard-resolver

This option forces the use of the system’s standard DNS resolver code. This is mainly used for debugging.
</snip>

I guess the best place for your question would be one of the GnuPG lists [2], probably either gnupg-users or gnupg-devel.

Cheers,
Albrecht.

[1] <https://www.gnupg.org/documentation/manuals/gnupg/Invoking-DIRMNGR.html>
[2] <https://www.gnupg.org/documentation/mailing-lists.html>
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list

attachment0 (484 bytes) Download Attachment
Loading...