Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #210300 > unrolled thread

gnupg / enigmail excessive processing times

Back to article view | Back to linux.debian.user

Contents

  gnupg / enigmail excessive processing times The Wanderer <wanderer@fastmail.fm> - 2019-06-23 16:20 +0200
    Re: gnupg / enigmail excessive processing times Teemu Likonen <tlikonen@iki.fi> - 2019-06-23 17:30 +0200
      Re: gnupg / enigmail excessive processing times The Wanderer <wanderer@fastmail.fm> - 2019-06-23 17:50 +0200
        Re: gnupg / enigmail excessive processing times Teemu Likonen <tlikonen@iki.fi> - 2019-06-23 19:40 +0200
          Re: gnupg / enigmail excessive processing times The Wanderer <wanderer@fastmail.fm> - 2019-06-29 02:50 +0200
    Re: gnupg / enigmail excessive processing times Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2019-07-02 18:20 +0200
      Re: gnupg / enigmail excessive processing times Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2019-07-02 19:00 +0200

#210300 — gnupg / enigmail excessive processing times

[Multipart message — attachments visible in raw view] — view raw

The short version of this is that I think I need to clear out a lot of
irrelevant keys / signatures, et cetera, from my gnupg configuration -
but I don't want to do anything which risks losing my private key(s), or
any related information.

Just in case I'm wrong about that solution, however, I want to lay out
the entire situation.


The primary way in which I make use of gnupg is via Thunderbird and the
Enigmail extension.

In addition to permitting me to sign and/or encrypt messages I send,
this serves to validate E-mails received from others, by checking the
signature against its associated public key.

It includes functionality to reach out to a designated keyserver and
download the matching public key for the signature in the currently open
E-mail, on demand. Doing this, however, takes at least a few moments -
and potentially considerably longer - for each such key request, and
blocks the Thunderbird UI until the request either completes or is
cancelled.

Some years ago, I got tired of manually importing the key every time I
saw a signed message through the Debian mailing lists for which I didn't
already have the necessary public key. As a handy shortcut, I simply
imported all keys from the debian-keyring package, which theoretically
should include all Debian developer/etc. public keys.

This mostly worked, in terms of reducing how many Debian-mailing-list
messages I saw with unrecognized public keys, but not entirely; there
were, and are, still a fair number of people whose messages were signed
with keys that apparently hadn't been included. That's fine, I can just
fetch those keys using the UI method, as before.

(I later repeated this import process, using a newer version of the
debian-keyring package. I don't know whether that would have had any
meaningful effect on the behaviors I observed later.)

Unfortunately, over time - and even more after the failed-RAID-array
recovery on which I've spent the past 6+ months, and which is the reason
I haven't posted here during that time - the time necessary to fetch a
new key has gone up to unreasonable levels; by now, processing a typical
new-key request seems to take something definitely in excess of 30
minutes, and possibly multiple hours, during which I can't otherwise
make use of my mail client. (I don't have any convenient way of timing
the process more exactly.)

During this time, gnupg is pegging one CPU core at maximum, and doing a
not entirely negligible amount of disk I/O. I'm guessing that it's
iterating through every single public key I've got in the local keyring,
although exactly what it's doing with each one I'm not sure enough to
state.

For reference, the file which I suspect contains those public keys -
~/.gnupg/pubring.gpg - is 131MB in size.


I suspect that importing the entire debian-keyring set was my original
mistake, and that I shouldn't have done that.

At this point, I'd be willing to un-do that step, and go back to
manually importing just the keys needed for the messages I actually
receive. Unfortunately, I suspect there's no practical way of
un-scrambling that egg; the keys imported that way are mixed in with the
ones received by other means, and it would not be trivial to try to
separate them out.

I'd also be willing to just discard my entire collection of imported
public keys, and start from scratch, if I knew of a way to do so which I
could be completely certain wouldn't have undesirable side effects on
other parts of my cryptographic situation - most particularly and
especially, my private key(s).

In between those, if there's a way of mass-discarding public keys which
fit (or don't fit) some particular criteria, while retaining others,
that might be preferable to either extreme.

However, so far I've been unable to find any way of removing keys from
the local key repository except 'gnupg --delete-keys [name]', which
appears to require specifying each key for removal one at a time. This
does not really scale to the point where I'm currently at.


Any suggestions for how to recover from this situation?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [next] | [standalone]

#210303

[Multipart message — attachments visible in raw view] — view raw

The Wanderer [2019-06-23 10:14:19-04:00] wrote:

> Some years ago, I got tired of manually importing the key every time I
> saw a signed message through the Debian mailing lists for which I didn't
> already have the necessary public key.

If you add line "auto-key-retrieve" to your ~/.gnupg/gpg.conf then GnuPG
will automatically try to retrieve keys from keyservers when you verify
a signature made by an unknown key. This may solve the problem of
importing too much keys and thus making your keyring large and slow.

> For reference, the file which I suspect contains those public keys -
> ~/.gnupg/pubring.gpg - is 131MB in size.

GnuPG key operations slow down when the keyring is large, especially if
the trust model is "pgp" and the program needs to check the web of trust
every time a new key arrives. One solution is to add
"no-auto-check-trustdb" in gpg.conf and only run manually "gpg
--check-trustdb" from time to time.

It also helps if you delete certificates (key signatures) made by
unknown keys. You can manually clean such certificates with "--edit-key
+ clean" or automatically for future operations with the following lines
in gpg.conf:

    import-options import-clean
    keyserver-options import-clean

See gpg manual page for more information about --import-options and
perhaps also --export-options.

There is no command for cleaning your current keyring but it can be
automated with a simple script:


    #!/bin/sh
    gpg --batch --with-colons --list-keys | awk -F: '
    $1 == "pub" {pub = 1}
    pub == 1 && $1 == "fpr" {printf "%s clean save\n", $10; pub = 0}' | \
            xargs -n3 -- gpg --batch --no-auto-check-trustdb --edit-key


The above script runs

    gpg --batch --no-auto-check-trustdb --edit-key FPR clean save

for every key (FPR is key's fingerprint).

-- 
/// Teemu Likonen   <https://github.com/tlikonen> //
// PGP: 4E1055DC84E9DFF613D78557719D69D324539450 ///

[toc] | [prev] | [next] | [standalone]

#210304

[Multipart message — attachments visible in raw view] — view raw

On 2019-06-23 at 11:23, Teemu Likonen wrote:

> The Wanderer [2019-06-23 10:14:19-04:00] wrote:
> 
>> Some years ago, I got tired of manually importing the key every
>> time I saw a signed message through the Debian mailing lists for
>> which I didn't already have the necessary public key.
> 
> If you add line "auto-key-retrieve" to your ~/.gnupg/gpg.conf then
> GnuPG will automatically try to retrieve keys from keyservers when
> you verify a signature made by an unknown key. This may solve the
> problem of importing too much keys and thus making your keyring large
> and slow.

An interesting suggestion. I'm not sure how it'd interact with Enigmail
(which is what is actually initiating the verification), but it's worth
investigating.

>> For reference, the file which I suspect contains those public keys
>> - ~/.gnupg/pubring.gpg - is 131MB in size.
> 
> GnuPG key operations slow down when the keyring is large, especially
> if the trust model is "pgp" and the program needs to check the web of
> trust every time a new key arrives.

I'm fairly sure that I'm using the default, which appears to be the one
specified by '--gnupg', so it's '--openpgp' plus compatibility
workarounds. I doubt it's any of the '--pgp[678]' modes.

> One solution is to add "no-auto-check-trustdb" in gpg.conf and only 
> run manually "gpg --check-trustdb" from time to time.

I'll try that first; I'm reading through the man page with an eye out
for this right now.

It seems entirely possible that this may be enough to get times back
into a reasonable range, just by itself. Thanks for suggesting it!

> It also helps if you delete certificates (key signatures) made by
> unknown keys.

What is an "unknown key" in this context? (And see note below.)

> You can manually clean such certificates with "--edit-key + clean" or
> automatically for future operations with the following lines in
> gpg.conf:
> 
>     import-options import-clean
>     keyserver-options import-clean
> 
> See gpg manual page for more information about --import-options and
> perhaps also --export-options.

I saw the 'clean' options (and 'minimal', relatedly), but wasn't sure
enough about what the impact of reducing the keys that way would be
willing to try it out without either asking for input or taking
backup-related precautions.

> There is no command for cleaning your current keyring but it can be
> automated with a simple script:
> 
> 
>     #!/bin/sh
>     gpg --batch --with-colons --list-keys | awk -F: '
>     $1 == "pub" {pub = 1}
>     pub == 1 && $1 == "fpr" {printf "%s clean save\n", $10; pub = 0}' | \
>             xargs -n3 -- gpg --batch --no-auto-check-trustdb --edit-key
> 
> 
> The above script runs
> 
>     gpg --batch --no-auto-check-trustdb --edit-key FPR clean save
> 
> for every key (FPR is key's fingerprint).

How sure can I/we/etc. be that this will not have any negative side
effects, in terms of eliminating key-related functionality that I
actually want to keep?

In case it's relevant, please note that I have done basically nothing as
far as keysigning or other web-of-trust activity; I'm using signature
verification as primarily a means of confirming A: that "yes, this mail
was signed by the key it says it was signed by", and B: "yes, this mail
was signed by the same key as that mail, so both mails were sent by the
same person". I don't have any web-of-trust confirmation about the
identity of the signer beyond that, and in practice for my purposes I'm
not entirely sure I care about getting it.

Before doing this, I'd probably want to back up ~/.gnupg/ in any case.
I suspect that I'd want to make sure gpg-agent, dirmngr, etc., are
stopped before doing that, or restoring the backup, in order to ensure
consistency.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#210310

[Multipart message — attachments visible in raw view] — view raw

The Wanderer [2019-06-23 11:46:34-04:00] wrote:

> On 2019-06-23 at 11:23, Teemu Likonen wrote:
>> If you add line "auto-key-retrieve" to your ~/.gnupg/gpg.conf then
>> GnuPG will automatically try to retrieve keys from keyservers when
>> you verify a signature made by an unknown key.

> An interesting suggestion. I'm not sure how it'd interact with
> Enigmail (which is what is actually initiating the verification), but
> it's worth investigating.

I have never used Enigmail but if it executes "gpg --verify" then gpg
will try to fetch (using dirmngr) a missing key from keyserver before
verifying the signature.

>> GnuPG key operations slow down when the keyring is large, especially
>> if the trust model is "pgp" and the program needs to check the web of
>> trust every time a new key arrives.
>
> I'm fairly sure that I'm using the default, which appears to be the
> one specified by '--gnupg', so it's '--openpgp' plus compatibility
> workarounds. I doubt it's any of the '--pgp[678]' modes.

The default --trust-model is "auto" which is means that it uses the
trust model that is saved to trust database (I guess trustdb.gpg). That,
in turn, means normally trust model "pgp" (i.e., web of trust based on
key signatures). And that trust model needs some calculations which take
time on large keyrings.

>> It also helps if you delete certificates (key signatures) made by
>> unknown keys.
>
> What is an "unknown key" in this context? (And see note below.)

Unknown to your keyring. See "gpg --list-signatures" and you'll probably
see that there are key many key signatures that can't be shown because
your keyring doesn't have the signer's key.

Command "--edit-key + clean" removes those unknown key signatures as
well as older key signatures if there are many from same signer. This
"clean" thing can very much reduce the size of your keyring, if you want
that. From gpg(1) man page:

    --edit-key

    [...]

        clean  Compact (by removing all signatures except the selfsig)
               any user ID that is no longer usable (e.g. revoked,  or
               expired).  Then,  remove  any  signatures  that are not
               usable by the trust calculations.   Specifically,  this
               removes  any signature that does not validate, any sig‐
               nature that is superseded by a later signature, revoked
               signatures,  and signatures issued by keys that are not
               present on the keyring.

> In case it's relevant, please note that I have done basically nothing as
> far as keysigning or other web-of-trust activity;

Then perhaps "--trust-model tofu" (or tofu+pgp) is better choice? Of
course you decide all that but web of trust (--trust-model pgp) is
useless unless user has signed (at least locally) some keys and usually
also trusts some others as signers (ownertrust).

-- 
/// Teemu Likonen   <https://github.com/tlikonen> //
// PGP: 4E1055DC84E9DFF613D78557719D69D324539450 ///

[toc] | [prev] | [next] | [standalone]

#210478

[Multipart message — attachments visible in raw view] — view raw

On 2019-06-23 at 13:32, Teemu Likonen wrote:

> The Wanderer [2019-06-23 11:46:34-04:00] wrote:
> 
>> On 2019-06-23 at 11:23, Teemu Likonen wrote:
>>> If you add line "auto-key-retrieve" to your ~/.gnupg/gpg.conf
>>> then GnuPG will automatically try to retrieve keys from
>>> keyservers when you verify a signature made by an unknown key.
> 
>> An interesting suggestion. I'm not sure how it'd interact with 
>> Enigmail (which is what is actually initiating the verification),
>> but it's worth investigating.
> 
> I have never used Enigmail but if it executes "gpg --verify" then
> gpg will try to fetch (using dirmngr) a missing key from keyserver
> before verifying the signature.

I haven't tried this yet, but it's still on my consideration list.

The reason I'm replying is to report that 'no-check-trustdb' does seem
to have done the trick! Without it, occasionally I would have a random
fetch attempt succeed in seconds with no issues; now that seems to be
happening every time.

I've also added a nightly cron job (in my user-specific crontab) with
"gpg --batch --check-trustdb --quiet 2>&1 | grep -v '^gpg: no need for a
trustdb check$'", to make sure that the check does get run periodically
when it's needed, but also not send me mail every day just to report
that nothing was done.

(Running that command when a check *is* needed seems to actually print
the exact, full text I was seeing in the Enigmail results dialog, as a
prefix to the actual fetch results, on every fetch attempt. I suspect
that some of it may represent useless or problematic keys, but I don't
know how to parse it well enough to figure out what to do about the
information.)

>>> GnuPG key operations slow down when the keyring is large,
>>> especially if the trust model is "pgp" and the program needs to
>>> check the web of trust every time a new key arrives.
>> 
>> I'm fairly sure that I'm using the default, which appears to be
>> the one specified by '--gnupg', so it's '--openpgp' plus
>> compatibility workarounds. I doubt it's any of the '--pgp[678]'
>> modes.
> 
> The default --trust-model is "auto" which is means that it uses the 
> trust model that is saved to trust database (I guess trustdb.gpg).

Ah. I was looking at the wrong part of the man page; thanks for
clarifying what this was referring to.

>>> It also helps if you delete certificates (key signatures) made
>>> by unknown keys.
>> 
>> What is an "unknown key" in this context? (And see note below.)
> 
> Unknown to your keyring. See "gpg --list-signatures" and you'll
> probably see that there are key many key signatures that can't be
> shown because your keyring doesn't have the signer's key.
> 
> Command "--edit-key + clean" removes those unknown key signatures as 
> well as older key signatures if there are many from same signer.
> This "clean" thing can very much reduce the size of your keyring, if
> you want that. From gpg(1) man page:

I saw that in the man page, but I wasn't sure what it would mean in
practice, especially since none of my keys (except my personal key) are
signed for web-of-trust purposes. I was afraid that the lack of a
web-of-trust signature chain would mean *all* of these keys would be
deleted by the clean process.

Am I correct in thinking that if I kill any running background
gpg-related process (gpg-agent, dirmngr, etc.), make a backup copy of
~/.gnupg/ (or possibly even just ~/.gnupg/pubring.gpg), and run this
command, I should be able to just revert to that backup copy in the
event that it turns out to have made changes I don't want?

>> In case it's relevant, please note that I have done basically
>> nothing as far as keysigning or other web-of-trust activity;
> 
> Then perhaps "--trust-model tofu" (or tofu+pgp) is better choice? Of 
> course you decide all that but web of trust (--trust-model pgp) is 
> useless unless user has signed (at least locally) some keys and
> usually also trusts some others as signers (ownertrust).

This is a good suggestion, and I'm considering it, but since things are
now working fine without having needed to make that change - and I'm not
sure I'll never want to use the web of trust, and I'm not sure how
safely reversible (without non-meaningless loss) changing trust models
in this direction is - I'm leaving this alone for the time being.

Thanks for the advice!

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#210611

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

On 24/6/19 12:14 am, The Wanderer wrote:
> The short version of this is that I think I need to clear out a
> lot of irrelevant keys / signatures, et cetera, from my gnupg 
> configuration - but I don't want to do anything which risks losing 
> my private key(s), or any related information.

Your problem is most likely polluted keys due to a major design flaw
with SKS serverv.

I've seen two keys become extremely large due to junk being added and
the behaviour of anything using my public keyring was horribly slow
and with the CPU pinning by one process.

The following has been sent to a couple of local LUGs that I'm in:

For those of us whom use OpenPGP/GPG keys with GNUPG implementation
(perhaps everyone whom interacts with SKS servers)... there has been a
very long standing technical problem that is currently causing issues.

The problem, in a nutshell causes keys to significantly increase in
size due to bad data being easily uploaded to the SKS servers without
proper validation and consequently severely effecting performance of
anything using the public keyring database.  If you experience the
problem, it will be due to a significant increase of the size of your
public keyring file.  When processing the public keyring data, the CPU
gets pinned at 100% for at least one thread.

What I have done is a full export of keys to ASCII armoured files and
look at the larger files -- in my case the two largest were for Micah
Lee and the Tor Project keys.  Delete problematic keys and import
fresh sane data for them.

Having older backups of the Tor Project's key, I've replaced the key
with one that doesn't have the extra bad payload.  The former key
/may/ not be easily found as the Tor website directs you to an SKS
server to collect the data and it doesn't appear to be easily
available directly from Tor project's own website.

For Micah Lee's key, I got it from keybase.io (micahflee).
   https://keybase.io/micahflee

There are different solutions, keybase.io is but one.  In any case the
SKS servers are in big trouble as they stand today.

A reason for the problem popping up might be related to a simple key
refresh; so that is a major problem.  It's been said that even just
using the keys can cause problems when you don't have any keys with
bad data, but I'm not so sure about that.


And a follow up:


Without any specific refresh, my Tor Project key grew again.

I've change my gpg.conf now, let's see if that stops the problem.

Using an alternate server:


keyserver hkp://keys.openpgp.org


More details here:
https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/

Cheers
A.
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXRuDNwAKCRCoFmvLt+/i
+zbSAP0Zh8WrQMJaEQRegRl+rBoNCucSSwySGAa4Iy/CbRr+GAD9G4FOYnJMs363
98asLeJ3TGuBWgjEqLVUItNH9HIOblE=
=uA5x
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#210613

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

> On 24/6/19 12:14 am, The Wanderer wrote:
>> The short version of this is that I think I need to clear out a
>> lot of irrelevant keys / signatures, et cetera, from my gnupg
>> configuration - but I don't want to do anything which risks losing
>> my private key(s), or any related information.
> 
> Your problem is most likely polluted keys due to a major design flaw
> with SKS serverv.

This looks interesting too, but unfortunately there are major
problems, performance is, but one, of the major problems.

https://daniel-lange.com/archives/159-Cleaning-a-broken-GNUpg-gpg-key.ht
ml

Kind Regards
AndrewM
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXRuMkQAKCRCoFmvLt+/i
+02QAQCnB0lAGSsUqjqiFDYhG4RKnng+5xmz5/Hrhm3frVOsWwEAhohuitUo88gI
MayoIpBEB0G+4faq+Ehw3QtcOhy5GWY=
=YZbA
-----END PGP SIGNATURE-----

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web