I see. Thanks for your explanation.

I'm unlikely to put a windows-specific patch into the debian source, as
i have no good way of testing it, and it wouldn't affect any binary that
we ship.

I see. Thus the problem is that IPWorksOpenPGP does not create proper OpenPGP private keys. I guess they use OpenSSL with their different CRT parameter style and do not convert them correctly. RFC-4880 says this in 5.5.3:

The secret key is this series of multiprecision integers:
o  MPI of RSA secret exponent d;
o  MPI of RSA secret prime value p;
o  MPI of RSA secret prime value q (p < q);
o  MPI of u, the multiplicative inverse of p, mod q.

It's been a while, any word on this? I sent the DCO as requested. Are there any technical concerns left to address?

I just received answer that this is still a problem in the current release.

@dkg: Please keep using slashes. The problem was that slashes are not allowed in git config keys. We use the branch name in some git config keys and thus they need to be mapped to soemthing different (ie. '-').

Last week:

• libgcrypt: merge X25519 api
• Make a topic branch for X25519 api: https://dev.gnupg.org/source/gnupg/history/gniibe%252Fx25519/

This week:

• libgcrypt adding X448 curve
• Gnuk adding X448 curve: 32-bit limb or 28-bit limb?

Thanks for your review.

It works for me.

@dkg, for your patch, it can be improved for Windows by using its event mechanism. You can see gnupg/scd/scdaemon.c.

Hm, T4521 suggests that the two different cases should not be treated differently. If you think that they *should* cause distinct behavior, please do mention it over there!

There are two different cases: (1) By SIGTERM and (2) By KILLAGENT. It's true that the agent stops accepting on the listening socket for (1), but it's not the case for (2).
This particular problem is for the case (2).

Werner, I interpreted jwilik's patch as admission of a problem from upstream, and reported it as such to CVE. I felt that since this does not effect the main platforms (ARM and x86_64) it would not be a big deal. If I interpreted wrong, I am sorry.

I assigned the CVE, but yes it needs more facts.

Andreas, I wonder on which grounds you assigned a CVE for this claimed side-channel attack. The mentioned paper is about an old RSA side-channel and not on AES. I would like to see more facts than the reference to a guy who knows PPC pretty well.

The gpg --version shows:

Which Libgcrypt version is used (gpg --version shows it).

This bug has been assigned CVE-2019-12904. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12904

I will work on OCB mode, eventually. Perhaps you could review what I have, but leave T4529 open until OCB mode is completed.

@gniibe, thanks for the diagnosis! I agree that restarting or shutting down the backends should be done in the reverse order as a simple workaround.

A possible exception here is that .onion TLDs should stick with HKP by default

Thanks, that's a good point. I'm adding gcry_ecc_get_algo_keylen.
I also changing the API for output (not allocating a buffer, but filling the buffer provided).

Correct solution is to implement KILLAGENT synchronously, but it's somehow harder to implement.
Easier workaround is modifying gpgconf like:

I found a race condition between KILLAGENT command and accepting another request.
Here is a patch to replicate the race condition :

I took this task as it has errors of gpg-connect-agent scd killscd. But, it seems for me that it's not the direct cause.
Anyway, I investigate the bug.

Would it be good to have interface for getting buffer size for different algos in this new interface? ... Similar as 'gcry_md_get_algo_dlen' for digest results.

Perhaps, returning allocated memory is not good. Filling the buffer for output would be better.

Shall we use secure buffer?

Hello,
when can we fix it?

without feedback, i have no idea what you want to do here as upstream. I believe this issue has identified a specific failing use case, and it has a patch that fixes the problem. if there's a problem, please let me know what it is. If there's no problem, please consider merging.

I note that "the best" seems like it might be a pretty subjective thing. The standard GnuPG framing asks about the validity of keys for the User ID in question. Perhaps the caller could indicate whether they want to require full validity for each key to make this key selection more strict.

The function would do something like:

• from msg, extract all e-mail addresses from to, cc, bcc fields
• find "the best" keys that match these addresses, storing them in keylist
• copy msg to tmp, remove bcc header from tmp
• wrap armored output of gpg.Context.encrypt(bytes(tmp), recipients=keylist) in the necessary RFC 3156 cladding, copying most headers from msg (maybe stubbing out the subject), producing an email.message.EmailMessage object.

Any word on this? i've pushed a fix for this into debian experimental as a part of 2.2.16-2, but i am concerned that there's no adoption from upstream. If there's a reason that this is the wrong fix, please do let me know!

I can't see any specific claim to the GPL. License 1 grants a royality free license for all open source implementations defined by the OSI. This includes the LGPL.
If you use Libgcrypt in non-open-source software you may get a free license using License 2.

fix building with hard ware acceleration off.

rebase

fix running with hardware acceleration off.

I'm so sorry. It was a problem with mail server, not a GpgOL bug.

Fixed in master, by using /usr/xpg4/bin/sh on Solaris.
Perhaps, some old Unix system like Tru64 would need same care.

I noticed it happens after entering the passphrase, and only using the
inline editor to answer.

we now have a DCO from @Valodim