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.

Signing using ECDSA does now also work. Tested with 3 in disk keys: nistp256, nistp384 and RSA and verified using gpgsm and Governikus Signer.

Basic en- and decryption test against Governikus_Signer has now been done. Beware: I had to add a debug option to gpgsm to workaround non-compliance in algorithm support of Governikus; see the rG68b857df13c8a4e6cae5e3a29fd065bf90764547 for details.

I'm not sure what to do here. The problem is that all users in clients without PGP/MIME Support will see the attachment names. That is why we use the names as they are.

It works for me(tm).

That would be awesome, thanks!

API-wise this would be possible because right now gpg errors out with

Done for master

Seems like this is applicable to other binaries as well:

On further thought, it's possible that something closer to what
Bernhard wants (and incidentally more along the lines of what I was
thinking of in some of our discussions just after the initial port)
might be achievable with Cython.

FWIW, GPGME is basically C90 and we only recently started to use C99 variadic macros - they are a cpp feature, though.

CFFI has no real means of generating the needed bindings on the fly
like SWIG does, except via its ABI methods, but those are inferior to
what SWIG does. It also can't handle all the ifdefs (or really any of
the ifdefs) in gpgme.h.

I am working on the Telesec Signature Card v2. I will add encryption support to gpgsm.

Nope, I was wrong.

Hi @slandden.
Do you have any updates?

It runs like:

$ gpg-connect-agent "scd devinfo --watch" /bye
S DEVINFO_START
S DEVINFO_END
S DEVINFO_STATUS new
S DEVINFO_START
S DEVICE generic D276000124010200F517000000010000 openpgp
S DEVINFO_END
S DEVINFO_STATUS removal
S DEVINFO_START
S DEVINFO_END
OK
$ 

Push the change to master.

genkey for Ed25519 works now with libksba in master.

For public key, it's done.

Thanks for following up!

No, we always stated that the user id is a mandatory part of OpenPGP keyblocks and that non-compliant keyblocks are rejected. The only exception we made are for revocation signatures where we allow a standalone packet. That exception is done to allow typing in a printed out revocation signature.

To be clear: marking this ticket wontfix means (among other things) that it is the GnuPG project's upstream position that:

With OpenPGP we made user ids mandatory to avoid problems we had with PGP2. I see no reason to revert this.

Nine months have passed since the patches for this problem have been available.

I recall that I talked with Stephan about it but things got lost.