I implemented subkey collapsing in 2.3. It is enabled by default but you can disable it it with

if a user decided to use the Web Key Directory, this should be used instead of falling back to whatever has been configured (nothing else by default)

On the ml there was another request for this use case

Unicode file names will now also work - see T4083 and T5030

Unfortunately we can't help you here as this is not a GnuPG problem or one of software we maintain.

Excellent! thanks for having considered this.

The options now work as documented. More tests on Window are required and eventually we need to handle non-ascii characters in file names.

Hello,
just reading the issue in detail.

Thanks. Added to 2.2.

For the reference of full mod_sqrt, see https://eli.thegreenplace.net/2009/03/07/computing-modular-square-roots-in-python/

Patch backported to 2.2

Any news on this?

C++ interface is also availabale in 1.14.0 (see rM690d967196d9).

As of today we don't want to maintain another binding; see T3395

The Python bindings are troublesome enough; as of today we don't want to maintain a Perl module.

C part done; C++ interface is not yet done.

• compressed representation of EC point can be used in:
  • public key
  • (exporting) private key
  • signature
  • ECDH ephemeral key
• Accepting compressed representation,for the initial implementation, I'd like to limit our effort for curves of NIST and Brainpool, except NIST P-224, which p = 3 mod 4.

Creating is not that useful - we prefer modern curves anyway.

I think that retrieving a parameter in compressed format is all what we need as per API.

(3) _gcry_ecc_os2ec in libgcrypt/cipher/ecc-misc.c should be modified to support parsing compressed representation.

What kind of API should we offer?
(1) offering something like q@comp name for gcry_mpi_ec_get_mpi
But...
If the intended use case will be in create_request function in gpg/sm/certreqgen.c, the 'q' is already generated in the form of SEXP.
It is up to an application (gpgsm), to convert non-compressed point representation to compressed point representation, here.

It's in master (to be gnupg 2.3).
Enjoy.

The qualitybar has now been removed from 2.2 and master.

We will need this for 1.9

Yes, its on my agenda.

Since this issue is what I came across when googling for gpg inspect revocation certificate, I thought I’d add what I found out:

I'd be interested, is this is still on the agenda?

Your welcome.

I regret to have distracted your attention. All the above applies to a terminal window (KDE's konsole) in my GUI KDE. On the bare FreeBSD console, everything is fine. So this is a bug in some KDE library or konsole. I'm sorry I did not have the idea to test that on the bare console right away. I'll close this bug here.

Hello Mr. Niibe,

It seems that nl_langinfo(CODESET) returns US-ASCII on your system.

My FreeBSD box is currently not up, so I can't test right now. You may want to look into gnupg/common/utf8conv.c and there set_native_charset(). For historical reasons we start off with latin-1 but then swicth to the selected charset and intialize iconv accordingly. In the case of an error we sometimes fallback to utf-8. You may want to add some debug code (log_debug ("foo bar string=%s\n", some_string);)

in your test, which you did on Linux I guess, utf-8 is written downcase, whereas on my system, it is written uppercase 'UTF-8, conforming to what I find elsewhere (e.g. Wikipedia and RFC 3629). I do not know though, if there is a recommended way to spell it. So the bug might be: gpg does not compare the RFC spelling uppercase, but the linuxism: utf-8 witten downcase. Then the correct fix would be to compare uppercase UTF-8 only, and let Linux fix their system to use the correct uppercase throughout the system... ;)
2nd, I know that FreeBSD has some issues with internationalization: it does not support charsets in their POSIX meaning, but emulates them by combining all available locales and (matching) CODESETs. Usually, this is not a problem, and most translations and handling of UTF-8 works as expected. Maybe this has some subtle effect causing this issue.

Hello Werner,

OpenPGP specifies the use of UTF-8 for all meta data (ie. everything except for the signed/encrypted data). GnuPG has always supported this. I don't known on which OS you are but some don't have UTF-8 support on the command line or tty so you need to tweak your environment first.

Shall we backport this to 2.2 which is our LTS release?

With the recent change the --sender option has an effect on the selection of the User ID used for the key validity check and the TRUST_ status lines:

MAPI Namespace has a pickFolder method which can be used here.

We already have the option --sender which does what @mgorny requests but only in the TOFU case. I need to revisit the system to see whether we can extend it to WoT and direct key signatures.

no prob

Uh, I just noticed that this issue is from dec. 2019 I am unsure why I overlooked this and only noticed it in my regular tracker check today.

@JJworx Thanks for the suggestion / feature request.

FYIL This is delayed because there are some dependencies to internals of gnupg.

Merged. Thanks.

Is there a blogpost or similar where the use of several smartcards following this improvement is explained to n00bs like me? :) For now all I find is this thread and some SE answers saying it does not work yet (https://security.stackexchange.com/questions/154702/gpg-encryption-subkey-on-multiple-smart-cards-issue) . If somebody could post a new answer on SE / write a small blog post or similar that would be great. Useful would be to have 1) from which versions and over is that available 2) how this works / how to use.

GnuTLS seems to have some CMS support; see https://gitlab.com/gnutls/gnutls/-/issues/227 .

libgpg-error used to be blamed because of this kind of architectural support in earlier stage of building operating system.
T4774 is my try to fix the problem.

Thank you for your work. Please go ahead.

If there's no objection to this in a few days, i'll go ahead and merge it to master.

I had assumed that GnuPG prioritized the safety of its users over strict adherence to a particular view of a cryptographic protocol

branch dkg/fix-4952 contains this fix in an easily applicable form as 0db8c768843db3e85935b972f1ed9d1b98159c46

Parsing and creating of certs does now work. I was not able to find sample CMS objects so this part is not yet finished.

Finished if an existing key is used. See rG6dc3846d78192e393be73c16c72750734a9174d1 for examples.

See rG6dc3846d78192e393be73c16c72750734a9174d1 for examples on how to create a cert

I'm moving this from testing to open again. Especially the deletion is an issue. I had a report that even for a sent mail Outlook.com also stores an unencrypted variant in the "Trash Bin".

Won't fix because there is no need for it. ASN.1 modules are the formal description of a protocol and as such not copyrightable.