Henry Spencer wrote three implementations (old, BSD, and Tcl): https://garyhouston.github.io/regex/
Indeed, for the one in old library and BSD library, \ + CHAR means that single CHAR.
For one in Tcl library, \s, \S, \w, \W is supported (just like GNU), and \d, \D (digit) is also supported.

ECDH on Curve25519 is fully supported in libgcrypt. You can see GnuPG supports ECDH on Curve25519.
Lower layer routines (point addition and point duplication) are not implemented, though.
That's because ECDH only requires point multiplication and it is better to implement point multiplication by Montgomery Ladder for Curve25519.

Fixed both for master and 1.8 branch.

It might be not a regression. The possibilities are: (1) it was tested by using non-GNU operating system. (2) Tests didn't cover characters (b, B, w, W, s, and S).

Yes, it will be in 2.2.3. It's too late for 2.2.2.

I believe this is due to the bug of gpg-agent. So, I put this report as a sub task under T3276: the calibrate_get_time() function depends on a system that has a non-tickless kernel.

This is a bug in gpg-agent.

Implemented in a branch: gniibe/scd-kdf-support

I confirmed that clock is better on FreeBSD, too. And FreeBSD has clock_gettime with CLOCK_THREAD_CPUTIME_ID.
I tested FreeBSD 11.1 running QEMU.

Could you please testing gpgme with D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available. for GnuPG?

# My update of D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available. has gone somewhere. So, I update it again.

Use clock instead of times.

Could you please try D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available. patch of GnuPG?

That's your building problem, not the problem of gnupg.

Yes, I put the tag of gpg2.2, as it's useful to compose key from external source.

Changes for Gnuk is done. It's now testing. It will be in Gnuk 1.2.7.

Did you run gpg before your copying $HOME data and after your installation of Stretch?
That gpg invocation create the file ~/.gnupg/.gpg-v21-migrated, which marks "the migration finished".

OK, closed.

GnuPG is picky about the order of options. Please put "--list-options show-photos" before -k.

How about adding support with private in keyparam?

• (genkey(rsa(nbit 2048)(d xxxx)(p xxxx)(q xxxx)(u xxxx))) ; Only p and q, is OK
• (genkey(ecc(curve cv25519)(flags djb-tweak comp)(d xxx)))

clock returns CPU time on POSIX, wall clock time on Windows. For threads, I don't know.

D441 applied. Closed.

Applied.

Thanks for testing and proposing new patch.

The code can be changed like:

• ENTRY_LOCK for mutual exclusion for ENTRY_CTX and pinentry communication
• Add ENTRY_OWNER_LOCK for mutual exclusion for accessing ENTRY_OWNER and ENTRY_LEVEL.

I'm going to change the code a bit.

How about D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available.?

Here is the list:

• libgcrypt
• libassuan
• ntbtls
• gpgme : autogen.sh is ready
• npth

rG3b66a256e376: agent: Allow recursive use of pinentry. fixes the test case above.
I wish it doesn't cause any other issues.

OK, I can make reproducible error case:

Applied to 2.2 branch.

I fixed for master.
It will be into 2.2.

Thanks for the information.
Closing, as I pushed rC94b84360ca55: Add OID information for SM3..

OK, I found: http://www.oidchina.cn/oid/release/1.2.156.10197.
站点： 国家OID注册中心
数字OID： 10197
中文OID：
英文OID： sca10197
应用范围： 密码标准化技术委员会

I use: 1.2.156.10197.1.401

I am now examining OID allocation.
I'll add the OID of SM3 into sm3.c.

For this proposed change, it is merged.
I'll add OID thing.

I'm going to add your change except src/gcrypt.h.in.

IIUC, it's defined by the agency in 2010, and then it was published as the national standard: GM/T 0004-2012 SM3密码杂凑算法

Thanks for your quick response.

For the implementation, it looks good for me.
I have suggestions and some requests.

I am closing this bug report, as I can't get feedback to fix something.

GnuPG 1.4 is only for old features. New features are only supported by GnuPG 2.2.

This is my note.
If it is intended to be used to OpenPGP, GCRY_MD_SM3 should be assigned in OpenPGP standard.

Thank you. The diff doesn't include sm3.c. Could you please update?

OK, I managed to replicate the failure of apt. Please note that it's not the failure of gpg.
So, your bug report is marked "Invalid", as a bug of gpg. Please understand that.

It seems that you have confusion between gpgv and gpg, and using "trust".

From my viewpoint, it works well. Just you don't have a permission to install the library to the directory.

For workaround (master branch with rG0a7661129499), moving the private key file to *.key.bak can do that.