dirmngr component of GnuPG
by mike acker from LinuxQuestions.org on (#55GCF)
what appears to be the current documentation for GnuPG ( online )
( https://gnupg.org/documentation/manuals/gnupg.pdf )
States:
" Since version 2.1 of GnuPG,dirmngr takes care of accessing the OpenPGP keyservers. "
Evidently, without this "dirmngr" component GnuPG cannot poke around in the sks keyserver pool
( keyserver http://hkps.pool.sks-keyservers.net:11371 )
the reference to the keyserver pool being provided in
( .gnupg/gpg.conf ) where the "keyserver" line specifies what should be referenced when a keyserver is needed.
evidently this created quite a mess as there are several GnuPG commands that depend on access to the keyservers..... search, receive, send,
evidently there is now only a weak dependency in the GnuPG package to this "dirmngr" component such that systems ends up without the services of the sks-keyservers
evidently hkp://keys.gnupg.net was established as a private gnupg keyserver to attempt to remedy this; instead it seems to have crippled the search/recv functions for keys ...
Question: do we have ( I'm sure we do so where can I find ) a white paper discussing this issue and describing the proper remedy ?


( https://gnupg.org/documentation/manuals/gnupg.pdf )
States:
" Since version 2.1 of GnuPG,dirmngr takes care of accessing the OpenPGP keyservers. "
Evidently, without this "dirmngr" component GnuPG cannot poke around in the sks keyserver pool
( keyserver http://hkps.pool.sks-keyservers.net:11371 )
the reference to the keyserver pool being provided in
( .gnupg/gpg.conf ) where the "keyserver" line specifies what should be referenced when a keyserver is needed.
evidently this created quite a mess as there are several GnuPG commands that depend on access to the keyservers..... search, receive, send,
evidently there is now only a weak dependency in the GnuPG package to this "dirmngr" component such that systems ends up without the services of the sks-keyservers
evidently hkp://keys.gnupg.net was established as a private gnupg keyserver to attempt to remedy this; instead it seems to have crippled the search/recv functions for keys ...
Question: do we have ( I'm sure we do so where can I find ) a white paper discussing this issue and describing the proper remedy ?