Sure, but lets use that ticket for this. if you have another topic, feel free to open another ticket.

Good idea.

for user ID selection, you could also potentially match on substring, so uid dkg could select/deselect all user IDs that contain "dkg".

Mnemonics can be made language independent by implementing wordlists for every language. In bip39, each word represents a number, 0 through 2047 (their index in the wordlist).

How scdaemon responds when there is no card available?

Though not directly related to our issues, this bug report on the MSYS2 site reported by their users encountering trouble with GPGME provides additional weight to irreconcilable differences between MSYS2 and GnuPG:

yes. that's why i wrote it in '['-brackets.
but usually, in info-documents a synopsis is written about it.
I think that it's not self-evident, that "you can either give a file or let the tool read from stdin or output to stdout" and therefore should be written explicitly.

The --auto-expand-secmem option is available in 2.2. and master for quite some time. It works if libgcrypt 1.8.2 or newer is used.

Will go into 2.1.12 to be released next week.

Commit 8613727f1ee985c3cfa2c815523312914f033ffd adds considerable detail on both the issues affecting compiling and installing a Windows version of the bindings and what it would take to actually resolve it.

That is good.

Just a heads up to everyone, Fedora is moving forward with this change for Fedora 30 (currently rawhide). https://bugzilla.redhat.com/show_bug.cgi?id=1656282 is the bug tracking it.

Cool and yes, that could also be an option. I was explicitly told by KDE-Windows that this would work for them, too. The problem for me is that I feel comfortable to add a CMake Buildsystem for the Cpp and Qt bindings (maybe Python?). It would be very simple for me, I would not extend it to GPGME core, at least not at first. I could do that on GNU/Linux without having to test an MSVC build.
It will be more effort for me to make autotools work nicely with MSVC. I would have to test that etc.

Just to stress it; I am in favor of allowing builds using other compilers. We allow this on Unix and so we should allow this on Windows as well. We should remember to use different DLL names to make it explicit that a certain DLL is targetting a specific ABI.

Another build systems does not solve your problem. If you want to support another toolchain, that is fine. But it can as well be done with the current build system. it is a matter of adding a new platform triplet to make sure we are not linking against different libc versions. In fact we can build all our code on a wide range of platforms with very different compilers, so supporting MSVC won't be a problem. Mixing them is a bad idea as can be shown by the usual cross-runtime malloc/free problems.

Further discussion revealed that the main problem is QtWebengine, which is a requirement of KMail and basically a fully fledged web browser with millions of lines of code. QtWebengine is only supported for MSVC on Windows and a MinGW port is not feasible, so just compiling KMail with MinGW all the way through like I did in the past is no longer an option. :-(

I give this high priority. This blocks for years that the KDE-Windows initiative provides a way to install the very good crypto MUA KMail on windows. They rely on MSVC (you can say that this is bad, but it is a fact of life). As a former member of that community I am a bit ashamed that I made it harder / impossible for them to build KMail with MSVC because I've moved it to GPGME proper.

I think that is something I want to grapple with next year. The maintainer of KDE 4 windows noted that they currently rely on the patches from:

..... And now after looking into this a bit deeper after attempting to build gpg-agent for windows, it appears that this is a bit deeper than the logic above (which is actually sound, when I read it for the second time)

Sorry I did not see your first comment.

I would change gpgme_addrspec_from_uid and the gnupg equivalent to strip out the subaddress.

It does not make sense to handle this in the protocol. The client should always ask for joe@example.org and thus keep the whole thing mostly out of gpg. This requires that keys are not created with sub-addresses. However, if someone has a need for this, this strategy should work:

Sorry, it didn't made it into 2.2.11.

It actually tries several servers but we need to set a limit because we need to cope with longer timeouts. Do you suggest to toggle between v4 and v6 addresses? That is if a v6 address fails, first try the next v4 address and it that fails, another v6 address, etc.

That it will not be a problem on that or near that date but already now because some use expiration times of 20 years.

what does "not only on Jan 19, 2038" mean here?

I hope I did not choose inappropriate action in commenting here that I also would highly appreciate a cache timeout for OpenPGP Cards to reduce the exposure time of already unlocked card's keys. Would be great to get such an option

The next version will have a details button to show the actual gpg output. This will often be helpful.

The "Copy" menu item already copies public keys to the clipboard.
I now added a private key key copy option to the context menu.

While I agree that it would be good for some useful comment to be generated, I'd currently settle for a way to manually set a comment on a key.

I believe this would be a good improvement in user experience

ok, feel free to close this ticket then. It's disappointing that there
seems to be no sane, simple, private multi-channel communication
mechanism avaiable cross-platform that GnuPG can rely on.

I have this use case: A card based encryption key is used as a subkey on one of my keys but also on another key of mine. The reason for this can be that I want to have separate keys (with different fingerprints) for two user ids but still use the same card for decryption. Sure it is possible to figure out that the user ids belong together but it is not obvious on first sight. Another use case is a role account with a shared subkey with only one administering the primary key.

This was additionally reported as https://bugs.debian.org/909755 -- it would be great to get a clear statement from the GnuPG project about handling the curated keyring use case.

I want to be able to create an ed448 key using gpg, use it to sign things.

Please write a proper feature requests. Two words are bit too brief. You should indicate for what you want ed448 support: gpg, gpgsm, libgcrypt etc.

Interaction will be something like this:

Priority is high, because Gnuk Token requires this feature for testing its implementation.

Maybe not on Linux but the environment is visible from other processes in the same way as the command line. So I don't see why we should add yet more clumsy passphrase workarounds to gpg. We already have PINENTRY_USER_DATA which can fulfill the same task.

i note that my patch doesn't include an addition to the test suite, which it probably should, though i'm not fluent in gpgscm. if someone could update it to include a test, i'd appreciate that, and would probably learn from the commit. I imagine the test would do something like:

I tried to push commit 07c19981da0607dc442fadc4079b1d71fbef8f83 to branch dkg/passphrase-env on playfair, but i got this complaint:

Well, the counterpart in gpg-agent is missing.

Gpg4win-3.1.3 was released.

Assuming dirmngr is just connecting to localhost on one of the following ports: 9050, 9150 or 8118 (maybe) then an interim workaround could be achieved with ncat (or netcat, or nc ... but ncat is like those two on steroids and will happily pass a shell exec function to connect to the remote host with openssl too (which may be preferred depending on the size of the LAN).

BTW: For TSA keys an additional key (usage) flag ("This key may be used for time-stamping") in RFC 4880bis would be nice. What do you think?

According to RFC 3628 there are two additional conditions to consider:

A timestamp or a time mark (which is an audit record kept in a secure
audit trail from a trusted third party) applied to a digital
signature value proves that the digital signature was created before
the date included in the time-stamp or time mark.

We won't fix that. If you want to build for Apple iOS make sure to use

We won't do that. Those with badly encoded user ids should create new keys or meanwhile have done so. The whole charset back and forth encoding adds a lot of complexity for some legacy applications. Frankly I would like to get rid of all code conversions and stick to utf-8.

In T3464 is is described how you can do it. Sure, in your case you want to have a home directory so that the agent and pinentry can work. --no-keyring makes sure that a decryption with a private key can't happen. How we have the cache for symmetric encrypted data which you can disable with --no-symkey-cache.

I'm sorry but the explanation you give does not address the original issue I described, and which dkg then clarified. The discussion about AE is tangentially related, but the issue I described relates to the gpg interface:

To use encryption and for both purposes: encryption and authentication.

Thank you!

Will be in 2.2.10

The question is now to model the API for this. For 0x02 it seems to be pretty clear: We assume it is a detached signature on a zero length file and make sure that no signed file is given.

With -beta24 the crash on send should also be gone. I've removed the option for the workaround as I expect that it is no longer necessary. (Yeah I'm an Optimist :-P )

Attached is a timestamp signature created with the test key (alfa, alpha, alice) from tests/openpgp.