dkg (Daniel Kahn Gillmor)
User

Projects

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Wednesday

  • Clear sailing ahead.

User Details

User Since
Mar 27 2017, 4:49 PM (112 w, 5 h)
Availability
Available

Recent Activity

Today

dkg added a comment to T4106: Terminal use case for gpg-agent and gpg-agent for ssh-agent feature.

trigger what command? i'm pretty sure it does not trigger updatestartuptty. And it should not do so, afaict -- if you think it should, i'd be interested in hearing the rationale for it.

Mon, May 20, 5:28 AM · Debian, gpgagent, Bug Report

Yesterday

dkg created T4522: gpg-agent's EXPORT_KEY command does not tell its pinentry SETKEYINFO , preventing use of external passphrase cache .
Sun, May 19, 10:43 PM · Bug Report, gpgagent
dkg created T4521: gpg-agent behavior on SIGTERM differs from KILLAGENT handling.
Sun, May 19, 9:17 PM · Bug Report, gpgagent
dkg added a comment to T4106: Terminal use case for gpg-agent and gpg-agent for ssh-agent feature.

This doesn't sound systemd-specific to me, fwiw, though i don't understand how to reproduce the problem from the given description here.

Sun, May 19, 9:05 PM · Debian, gpgagent, Bug Report

Thu, May 16

dkg added a comment to T4511: dirmngr error logs claim that HTTP GET requests are percent-escaped, but they are not.

"requires too much changes" i can understand.

Thu, May 16, 11:00 PM · Bug Report, dirmngr

Tue, May 14

dkg committed rC0df498e81fd3: use https instead of cleartext http where possible (authored by dkg).
use https instead of cleartext http where possible
Tue, May 14, 10:43 PM
dkg added a comment to T4516: use https: links internally where possible instead of http:// in libgcrypt source.

(hm, i'm pushing apparently successfully to playfair.gnupg.org:/git/libgcrypt.git but it is not showing up here. if you want to fetch this patch, you can also find it on the http-to-https branch at https://gitlab.com/dkg/libgcrypt.git

Tue, May 14, 10:35 PM · libgcrypt
dkg created T4516: use https: links internally where possible instead of http:// in libgcrypt source.
Tue, May 14, 10:30 PM · libgcrypt
dkg added a comment to T4511: dirmngr error logs claim that HTTP GET requests are percent-escaped, but they are not.

I think you are saying that dirmngr receives the query term as escaped data in the assuan connection from the dirmngr client (typically, gpg, which itself decides how to percent-escape what it feeds into libassuan).

Tue, May 14, 4:10 PM · Bug Report, dirmngr
dkg added a comment to T4514: Batch mode/unattended key generation: support multiple subkeys.

I think you'll be better off doing this with the simpler --quick-generate-key and --quick-add-key interfaces, rather than hacking on the domain-specific language used by --batch --generate-key.

Tue, May 14, 7:55 AM · gnupg (gpg23), Feature Request
dkg updated the task description for T4512: gpg's --keyserver option should be more robustly deprecated.
Tue, May 14, 7:42 AM · Documentation, gnupg (gpg22), Keyserver, dirmngr, Bug Report
dkg edited projects for T4466: Clean up --keyserver documentation in gpg(1), added: dirmngr, gnupg (gpg22), Keyserver; removed gnupg.
Tue, May 14, 7:40 AM · Keyserver, gnupg (gpg22), dirmngr, Documentation
dkg added a comment to T4490: --export-secret-keys fails with unusually-created secret key.

I think this patch should be backported to STABLE-BRANCH-2-2

Tue, May 14, 6:35 AM · ssh, gnupg (gpg22)
dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

I think this patch should be backported to STABLE-BRANCH-2-2

Tue, May 14, 6:35 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

I can confirm that this fix repairs the problem on debian's s390x.

Tue, May 14, 6:15 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

I've just pushed e4a158faacd67e15e87183fb48e8bd0cc70f90a8 to branch dkg/fix-T4501 as a proposed fix for this specific problem (it doesn't introduce anything in the test suite, or try to deal with any of the other %b problems).

Tue, May 14, 6:15 AM · gnupg (gpg22), Bug Report
dkg committed rGe4a158faacd6: agent: correct length for uri and comment on 64-bit big-endian platforms (authored by dkg).
agent: correct length for uri and comment on 64-bit big-endian platforms
Tue, May 14, 6:14 AM
dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

OK, i think the reason this is happening is that agent_public_key_from_file (in agent/findkey.c) is screwing up a %b format string in gcry_sexp_build_array.

Tue, May 14, 5:57 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

Ok, the difference appears to be that on these 64-bit big-endian platforms, they're returning a zero-byte string for the associated comment. When this happens, gcry_sexp_canon_len returns 0 because of GPG_ERR_SEXP_ZERO_PREFIX. The same thing happens on x86_64 platforms when confronted with such an s-expression.

Tue, May 14, 5:07 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

It looks to me like gcry_sexp_canon_len is returning 0 on these platforms from within a backtrace like this:

Tue, May 14, 4:21 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4490: --export-secret-keys fails with unusually-created secret key.

I've just pushed 29adca88f5f6425f5311c27bb839718a4956ec3a to the dkg/fix-T4490 branch, which i believe fixes this issue.

Tue, May 14, 3:43 AM · ssh, gnupg (gpg22)
dkg committed rG29adca88f5f6: gpg: enable OpenPGP export of cleartext keys with comments (authored by dkg).
gpg: enable OpenPGP export of cleartext keys with comments
Tue, May 14, 3:43 AM
dkg added a comment to T4507: show-only-fpr-mbox shows user-ids that are not valid.

Validity values are also displayed for all user IDs.
[…]

show-uid-validity
       Display  the  calculated  validity of user IDs during key
       listings.  Defaults to yes.

[…]

Trust values are used to indicate ownertrust and validity of  keys  and
user IDs.  They are displayed with letters or strings:

[…]

revoked
       For validity only: the key or the user ID has been revoked.
Tue, May 14, 2:30 AM · Bug Report
dkg committed rGf4dfeb9c80e1: doc: clarify intent for show-only-fpr-mbox (authored by dkg).
doc: clarify intent for show-only-fpr-mbox
Tue, May 14, 2:29 AM
dkg added a comment to T4448: Add "Autocrypt" key-origin.

@werner, why is it the case that if i'm willing to look up a key via WKD on Monday, i should by definition also be willing to send a followup request to that WKD server on Thursday just because the certificate is marked with an expiration?

Tue, May 14, 2:17 AM · Feature Request
dkg added a comment to T4490: --export-secret-keys fails with unusually-created secret key.

And, i just discovered that when i manually edit the key to remove the (comment) list from the *.key S-expression file, everything works fine on s390x. so the failure appears to be due to the presence of the (comment) clause. (same as in T4501)

Tue, May 14, 1:48 AM · ssh, gnupg (gpg22)
dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

And, i just discovered that when i manually edit the key to remove the (comment) list from the *.key S-expression file, everything works fine on s390x. so the failure appears to be due to the (comment), just like in T4490.

Tue, May 14, 1:37 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

fwiw, i've just tried loading the same keyfile that the s390x (64-bit big-endian) implementation choked on into a running gpg-agent on an amd64 machine (64-bit little-endian) and gpg --full-generate-key succeeded with that same key on amd64.

Tue, May 14, 1:35 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4513: dirmngr should try the configured keyservers anyway even if they are all dead.

This is particularly bad for users who have manually specified a given keyserver in dirmngr.conf, because even a transient failure in that keyserver will prevent them from any future keyserver requests until dirmngr decides that the "death" has worn off.

Tue, May 14, 1:00 AM · Feature Request, Keyserver, dirmngr
dkg created T4513: dirmngr should try the configured keyservers anyway even if they are all dead.
Tue, May 14, 12:54 AM · Feature Request, Keyserver, dirmngr
dkg created T4512: gpg's --keyserver option should be more robustly deprecated.
Tue, May 14, 12:49 AM · Documentation, gnupg (gpg22), Keyserver, dirmngr, Bug Report
dkg created T4511: dirmngr error logs claim that HTTP GET requests are percent-escaped, but they are not.
Tue, May 14, 12:19 AM · Bug Report, dirmngr

Mon, May 13

dkg added a comment to T4467: dirmngr keyserver option (and legacy gpg --keyserver) should assume `hkps://` or `hkp://` if no scheme is present.

further testing suggests that the invalid URI issue is only present for dirmngr's --keyserver option, and gpg's deprecated --keyserver option actually accepts schema-less hostnames.

Mon, May 13, 11:33 PM · dirmngr
dkg updated the task description for T4467: dirmngr keyserver option (and legacy gpg --keyserver) should assume `hkps://` or `hkp://` if no scheme is present.
Mon, May 13, 11:32 PM · dirmngr
dkg added a comment to T4493: Default to HKPS, not HKP.

see also T4467

Mon, May 13, 11:12 PM · dirmngr, Feature Request
dkg created T4507: show-only-fpr-mbox shows user-ids that are not valid.
Mon, May 13, 3:47 PM · Bug Report

Sun, May 12

dkg created T4503: include extension for OpenPGP creation timestamp in X.509 output.
Sun, May 12, 1:01 AM · Feature Request, S/MIME
dkg created T4502: keys added via gpg-agent's ssh-agent interface are stored in private-keys-v1.d/ with a trailing null byte.
Sun, May 12, 12:37 AM · gpgagent, ssh

Sat, May 11

dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

is a copy of another example generated key (not b64-encoded, if you want to just download it.

Sat, May 11, 4:24 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

I also did a base64 < "$GNUPGHOME/private-keys-v1.d/".key at the end of a different run of that script, and it produced this output, if you'd like to inspect the actual S-expression stored:

Sat, May 11, 4:21 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

I ran the example script from T4490 on an s390x machine, and got the following output:

Sat, May 11, 4:16 AM · gnupg (gpg22), Bug Report
dkg updated the task description for T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.
Sat, May 11, 12:37 AM · gnupg (gpg22), Bug Report
dkg set Version to 2.2.13 on T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.
Sat, May 11, 12:36 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.

This might be related to T4490, since it's the same sort of key generation process.

Sat, May 11, 12:36 AM · gnupg (gpg22), Bug Report
dkg created T4501: gpg --generate-key --batch from existing key (with Key-Grip:) fails on 64-bit big-endian architectures.
Sat, May 11, 12:33 AM · gnupg (gpg22), Bug Report

Fri, May 10

dkg created T4497: gpgconf should report clearer errors when it knows that a given daemon's config file is bad.
Fri, May 10, 11:24 PM · gnupg (gpg22)
dkg added a comment to T4490: --export-secret-keys fails with unusually-created secret key.

I was trying to use the above technique to be able to generate an OpenPGP transferable secret key in an ephemeral homedir. Ephemeral directories are recommended in the GnuPG info page's "unattended usage" section, but they do not work here.

Fri, May 10, 10:45 PM · ssh, gnupg (gpg22)
dkg created T4496: gpgconf --launch ignores --homedir arguments.
Fri, May 10, 9:25 PM · Bug Report, gnupg (gpg22)
dkg committed rGbe116f871dbf: doc: correct documentation for gpgconf --kill (authored by dkg).
doc: correct documentation for gpgconf --kill
Fri, May 10, 6:43 PM
dkg committed rG9662538be6af: doc: correct documentation for gpgconf --kill (authored by dkg).
doc: correct documentation for gpgconf --kill
Fri, May 10, 6:42 PM
dkg created T4490: --export-secret-keys fails with unusually-created secret key.
Fri, May 10, 6:28 AM · ssh, gnupg (gpg22)

Thu, May 9

dkg added a comment to T4489: gpg --quick-add-key should be able to add an existing key as a subkey, not just generating a new one.

i'm thinking that if the algo parameter to --quick-add-key is a keygrip, then it would find the key directly in the existing keyring(s) and attach it as a new subkey.

Thu, May 9, 12:15 AM · gnupg, OpenPGP, Feature Request
dkg created T4489: gpg --quick-add-key should be able to add an existing key as a subkey, not just generating a new one.
Thu, May 9, 12:14 AM · gnupg, OpenPGP, Feature Request

Wed, May 8

dkg created T4488: dirmngr: allow changing `use-tor` in a reload.
Wed, May 8, 1:57 PM · gnupg (gpg23), dirmngr
dkg reopened T4487: libksba: please refresh ASN.1 components from more recent RFCs with BSD licensing as "Open".

If the ASN.1 is not from an RFC, then the AUTHORS file should not claim that it is from an RFC.

Wed, May 8, 1:42 PM · libksba, Feature Request

Tue, May 7

dkg added a comment to T4457: Improve deletion of secret subkeys (don't delete primary key when subkey deletion is requested).

@werner could you review the patches posted here by @matheusmoreira ? This looks concretely useful, and i would like to have this fixed.

Tue, May 7, 11:16 PM · patch, Bug Report, gnupg

Mon, May 6

dkg created T4487: libksba: please refresh ASN.1 components from more recent RFCs with BSD licensing.
Mon, May 6, 11:53 PM · libksba, Feature Request
dkg added a task to rMbd2d282e572b: python/tests: try to decrypt and verify new test data: T4276: Context.decrypt() throws an error if *any* signature is bad.
Mon, May 6, 8:41 AM
dkg added a task to rM4100794e305b: python: stop raising BadSignatures from decrypt(verify=True): T4276: Context.decrypt() throws an error if *any* signature is bad.
Mon, May 6, 8:41 AM
dkg added a commit to T4276: Context.decrypt() throws an error if *any* signature is bad: rMbd2d282e572b: python/tests: try to decrypt and verify new test data.
Mon, May 6, 8:41 AM · gpgme, Python, Bug Report
dkg added a commit to T4276: Context.decrypt() throws an error if *any* signature is bad: rM4100794e305b: python: stop raising BadSignatures from decrypt(verify=True).
Mon, May 6, 8:41 AM · gpgme, Python, Bug Report

Fri, May 3

dkg added a comment to T4276: Context.decrypt() throws an error if *any* signature is bad.

I agree that this is a minor API shift, but i *don't* think it's a security problem, because i was particularly careful to maintain the invariant that decrypt(verify=True) will only ever return valid signatures.

Fri, May 3, 5:23 PM · gpgme, Python, Bug Report
dkg created T4481: gpgme 1.13.0 ships with an emacs backup file: lang/python/doc/src/gpgme-python-howto.tex~.
Fri, May 3, 2:07 PM · gpgme
dkg added a comment to T4477: gpgme has noisy warnings in debug.h.

Thanks for the prompt action here. Some build environments (e.g. distro builds) might ask for additional compiler warnings in the user-supplied CFLAGS, but i suppose those build environments that enable the warnings deserve what they get.

Fri, May 3, 2:02 PM · Bug Report, gpgme
dkg added a comment to T4276: Context.decrypt() throws an error if *any* signature is bad.

I've just published a branch dkg/fix-T4276 (with commit 4100794e305ba22241ea5a4f7b42bb5189fbd948) which i think resolves this issue.

Fri, May 3, 6:49 AM · gpgme, Python, Bug Report
dkg committed rMbd2d282e572b: python/tests: try to decrypt and verify new test data (authored by dkg).
python/tests: try to decrypt and verify new test data
Fri, May 3, 6:48 AM
dkg committed rM4100794e305b: python: stop raising BadSignatures from decrypt(verify=True) (authored by dkg).
python: stop raising BadSignatures from decrypt(verify=True)
Fri, May 3, 6:48 AM
dkg committed rMc5c3a9d10be4: tests: add two new types of encrypted data (authored by dkg).
tests: add two new types of encrypted data
Fri, May 3, 6:48 AM
dkg committed rM30bd1c097544: python: make it easier to run a limited number of tests (authored by dkg).
python: make it easier to run a limited number of tests
Fri, May 3, 6:48 AM
dkg created T4478: Please fix DeryptionError typo in gpgme python bindings.
Fri, May 3, 4:42 AM · Python, Bug Report, gpgme
dkg added a comment to D444: Fix Typo in Python Exception DecryptionError.

Fixing this is technically an API change, but i can find no evidence that this has ever been used by any consumer of the gpg module. (e.g. i searched in debian and on the public web)

Fri, May 3, 4:41 AM
dkg added a comment to D444: Fix Typo in Python Exception DecryptionError.

This is obviously correct. Why has it not been merged?

Fri, May 3, 4:39 AM
dkg created T4477: gpgme has noisy warnings in debug.h.
Fri, May 3, 4:29 AM · Bug Report, gpgme

Wed, May 1

dkg created T4476: gpgol should make it easy to attach the user's key.
Wed, May 1, 9:59 PM · gpgol, Feature Request

Sat, Apr 27

dkg updated subscribers of T4457: Improve deletion of secret subkeys (don't delete primary key when subkey deletion is requested).

Thanks for this work, @matheusmoreira ! I personally think a reusable function in common/ would be preferable, but it's probably up to @werner to decide what's best here.

Sat, Apr 27, 3:15 AM · patch, Bug Report, gnupg

Fri, Apr 26

dkg added a comment to T4457: Improve deletion of secret subkeys (don't delete primary key when subkey deletion is requested).

nice, i'm glad to hear you've got something working, @matheusmoreira ! if you can point to your branch, or send patches here so that other folks can review, that would be great.

Fri, Apr 26, 6:58 AM · patch, Bug Report, gnupg

Apr 19 2019

dkg added a comment to T4464: dane refers to draft-ietf-dane-openpgpkey-05, should be RFC 7929 .

Paul Wouters writes to me:

Apr 19 2019, 10:39 PM · gnupg, Documentation, Bug Report
dkg created T4468: twitter login broken.
Apr 19 2019, 10:33 PM · dev.gnupg.org
dkg created T4467: dirmngr keyserver option (and legacy gpg --keyserver) should assume `hkps://` or `hkp://` if no scheme is present.
Apr 19 2019, 5:26 PM · dirmngr
dkg created T4466: Clean up --keyserver documentation in gpg(1).
Apr 19 2019, 5:17 PM · Keyserver, gnupg (gpg22), dirmngr, Documentation
dkg added a comment to T4465: dirmngr's default tor autodetection mode should autodetect on each connection (falling back to non-tor when tor is unavailable).

I just noticed that dirmngr(8)'s documentation for its --keyserver option says:

Apr 19 2019, 5:11 PM · Tor, dirmngr, Bug Report
dkg committed rGea7d85ff658c: gpgconf: correct capitalization of "Tor" (authored by dkg).
gpgconf: correct capitalization of "Tor"
Apr 19 2019, 5:09 PM
dkg added a comment to T4465: dirmngr's default tor autodetection mode should autodetect on each connection (falling back to non-tor when tor is unavailable).

Note that even sending a HUP to dirmngr, when it is in this autodetection mode that observed tor at the start, is insufficient to have it re-run the autodetection. You have to explicitly terminate dirmngr to get it to unlearn the autodetected presence of Tor. This is subtly hinted at in dirmngr(8), but no justification is given for it.

Apr 19 2019, 4:47 PM · Tor, dirmngr, Bug Report
dkg created T4465: dirmngr's default tor autodetection mode should autodetect on each connection (falling back to non-tor when tor is unavailable).
Apr 19 2019, 4:36 PM · Tor, dirmngr, Bug Report
dkg created T4464: dane refers to draft-ietf-dane-openpgpkey-05, should be RFC 7929 .
Apr 19 2019, 1:30 AM · gnupg, Documentation, Bug Report

Apr 17 2019

dkg committed rPf74c4673e6b6: gnome3: correctly detect when no GNOME screenlock exists (authored by dkg).
gnome3: correctly detect when no GNOME screenlock exists
Apr 17 2019, 10:48 PM
dkg committed rP65d2c6d5911a: gnome3: Use the default dbus timeout when checking for screenlock (authored by Zephaniah E. Loss-Cutler-Hull <zephaniah@gmail.com>).
gnome3: Use the default dbus timeout when checking for screenlock
Apr 17 2019, 10:48 PM

Apr 11 2019

dkg created T4457: Improve deletion of secret subkeys (don't delete primary key when subkey deletion is requested).
Apr 11 2019, 5:27 PM · patch, Bug Report, gnupg

Apr 10 2019

dkg added a comment to T3767: simplify sharing dirmngr's across multiple GNUPGHOMEs.

One of the things that dirmngr has going for it is that it tracks the current network state, and it would be nice to be able to reuse that state across sessions. If an ephemeral keyring can't use a shared dirmngr, there are fewer arguments for having dirmngr in the first place, and people might be more justified in replacing it with things like https://gitlab.com/anarcat/scripts/blob/master/openpgp-key-get

Apr 10 2019, 2:52 AM · Documentation, Feature Request, gnupg, dirmngr

Apr 5 2019

dkg added a comment to T4448: Add "Autocrypt" key-origin.

does the proposed mail value indicate that the key was received over e-mail, or is it intended to have some more nuanced semantics?

Apr 5 2019, 4:47 PM · Feature Request

Apr 4 2019

dkg added a comment to T4448: Add "Autocrypt" key-origin.

@werner: what if the autocrypt header is in a dkim-signed message, and the dkim signature covers the autocrypt header, and the dkim signature is verifiable using dnssec? is it still the same as from a keyserver?

Apr 4 2019, 6:32 PM · Feature Request

Apr 2 2019

dkg created T4446: please add --quick-revoke-subkey.
Apr 2 2019, 5:41 PM · OpenPGP, gnupg (gpg23), Feature Request

Apr 1 2019

dkg committed rG5b1b5be65f34: NEWS: correct typo in header (authored by dkg).
NEWS: correct typo in header
Apr 1 2019, 4:36 PM

Mar 23 2019

dkg added a comment to T4418: --with-wkd-hash does not have an effect on --with-colons.

i don't think we need another column without the domain, i agree that it's easy enough to strip.

Mar 23 2019, 10:40 PM · Bug Report
dkg added a comment to T4418: --with-wkd-hash does not have an effect on --with-colons.

That seems plausible to me. I'm not sure why you'd include the @domain part in the output, since it's all strictly about the localpart. what happens if you provide some upper-case inputs?

Mar 23 2019, 3:48 AM · Bug Report
dkg created T4424: documentation for --no-keyring seems garbled.
Mar 23 2019, 3:07 AM · gnupg, Documentation, Bug Report
dkg added a comment to T3389: canonical OpenPGP certificate export.

fwiw, a comment over on T4422 contains a bash script that tries to force GnuPG to do its certificate/signature re-ordering. this doesn't produce anything canonical yet, but it's the closest i've come so far to getting GnuPG to do something repeatable with a certificate after merging (but even that is not quite stable).

Mar 23 2019, 2:34 AM · gnupg (gpg23), Feature Request
dkg added a comment to T4422: `repair-keys` does not reorder signatures on non-merge imports.

(fwiw, all of this testing is done with GnuPG 2.2.14-1, using the package that is in debian/experimental right now; i'd welcome any corroboration with other versions)

Mar 23 2019, 1:56 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4422: `repair-keys` does not reorder signatures on non-merge imports.

as i experiment with this, i find an even weirder result with certificate re-ordering: the function above is not idempotent.

Mar 23 2019, 1:55 AM · gnupg (gpg22), Bug Report
dkg added a comment to T4422: `repair-keys` does not reorder signatures on non-merge imports.

Here is a horrible bash function for doing the kind of stripping and re-importing that *does* cause signature re-ordering:

Mar 23 2019, 1:51 AM · gnupg (gpg22), Bug Report