Perhaps, as a library (considering the benefit of users), it would be better to allow signature verification with SHA-1, to defer the decision to application.

I have a little concern for glibc 2.34 (which has dummy libpthread and all is actually in libc).

(3-1) is implemented: rCa23cf78102f3: cipher: Reject SHA-1 for hash+sign/verify when FIPS enabled.

For a programmer like me, it is easier the behavior will be:

It was fixed in: rPTH223e59f992f9: build: Define _NPTH_NO_RWLOCK when we can't find pthread_rwlock_t.

The problem is that the SHA-1 as a digest algorithm itself is allowed in FIPS mode (for non-cryptographic digests), but using it as part of approved signature scheme is not allowed

The current code is inconsistent about its behavior: how non-approved digest algos are supported or not when FIPS enabled.

If .fips will mean FIPS 140-3, why not following?

diff --git a/cipher/sha1.c b/cipher/sha1.c
index 3bb24c7e..cb50ef66 100644
--- a/cipher/sha1.c
+++ b/cipher/sha1.c
@@ -759,7 +759,7 @@ static gcry_md_oid_spec_t oid_spec_sha1[] =

I created T5665: libgcrypt : Restrict message digest use for FIPS 140-3.

Let me move this ticket as DONE (now Testing status), as the subject was solved (MD5 and soft/forced/inactive things).

I investigated if the possible change above (if applied) constitutes an ABI change: Indeed, it will be an ABI change, and an API change; code should be modified and build.

Sorry, I was wrong. We don't need any changes.

I am going to implement rejecting SHA-1 through new API (hash+sign, hash+verify).

Last week:

• libgcrypt
  • T5645, T5636, T5617, doc for T4894
  • T5550: build-time supplying hmac key for validation (binary check)
• libksba: Bison and its yylex: T5616
• pinentry-curses: color support: T5631 and others
• dirmngr - dns: T565
• New Gnuk release for PC/SC and emulated Gnuk

This week:

• openpgp
  • Implement writing side of new448
• libgcrypt
  • more on constructor / global_init
• gnupg
  • consider PC/SC heuristic T5644 and use of virtual PC/SC driver

It seems for me that the patches to random/ was written in old days.

• Now, we have getentropy in libc
  • This is most reliable one
  • better than urandom, because it may block when kernel is not yet seeded
  • better than random, because it never blocks once kernel is seeded
• So, the real path in rndlinux.c is actually, call to getentropy
• No access to /dev/random or /dev/urandom any more, in fact
• Although old code remains, non-touched
  • like use of syscall when getentropy function is not available

Add doc in gcrypt.texi.

Thank you. Applied.

Thanks for testing. I pushed a fix for my typo: rPb713f31c5b04: curses: Fix the previous commit.

I don't know if it's same in your case, but to fix my case, I pushed a change {rG41eef36dc}

I managed to create a case. Put a line:

BTW, in your screen shot (log is preferred here), it shows 1c00, that must be actually written as AAAA (0x1c). In the bug T3803, we saw byte sequence like that, additional 00 was added then resulted malformed DNS packet.

OK, let us start discussion by applying the patch first.

Applied the RSA part.

Ah, other possible case is .. in hostname.

It's hard to investigate your problem, with no information of host for the query.
I mean, there is no case to replicate (for us).

Fixed in 2.3.3.

Fixed in GnuPG 2.3.3.

Fixed in GnuPG 2.3.3.

Thank you for locating the bug!

I should have explain the context.
No, there is no discussion about this in the WG.

I'm reading RFC5297, which says:

SIV can be used as a drop-in replacement for any specification that uses [RFC3394] or [RFC3217], including the aforementioned use. It is a more general purpose solution as it allows for associated data to be specified.

I think that a simple way is defining a table (string -> token) by ourselves in yylex, not enabling %token-table.
(Then, we don't need to depend on the feature of string with %token, which is not supported by POSIX yacc.)

Now configure with
--enable-hmac-binary-check="I know engineers. They love to change things." works.

Please tell me reader names to skip.

I push a change: rC070935965763: build: Use KEY_FOR_BINARY_CHECK for --enable-hmac-binary-check..

Last week:

• Investigate libccid problem on Fedora: done
• openpgp-dt
  • 448 can be implemented in GnuPG
    • no change required fore libgcrypt
    • only in gpg and gpg-agent
      • because opnepgp private key transfer format depends on OpenPGP
        • we need to change gpg-agent as wel
• libgcrypt
  • Fixed: T5637: Use poll for libgcrypt (support more than 1024 fds)
  • Cherry-picked to master from experimental branch: T4894: FIPS: RSA/DSA/ECDSA are missing hashing operation
• Fix for Solaris: T5623

This week:

• libgcrypt: T5645, T5636
• Argon2 in libgcrypt? possibly ask jussi about his idea/experience

Pushed the change: rC082ea0efa9b1: cipher: Add sign+hash, verify+hash, and random-override API.

Major problem here (before the change) was that clock_gettime returned an error with no valid value of the time, which confuses gpg-agent's calibration of time. This occurred on (not newest) Solaris kernel, as it offers clock_gettime function in the library and CLOCK_THREAD_CPUTIME_ID constant in the header.

FreeBSD has _POSIX_THREAD_CPUTIME > 0.
GNU/Linux has _POSIX_THREAD_CPUTIME == 0, because older kernel doesn't support the system call.

Reading pages of the following links:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html
https://docs.oracle.com/cd/E36784_01/html/E36873/unistd.h-3head.html

Thank you for your investigation.

How about:

• Only when hash-handle is used for multiple purposes, a user needs to compose SEXP
• when hash-handle is used for a single purpose, a user doesn't need to compose SEXP, but static one.

Last week:

• libgcrypt: done: T5581 and S390x thing.
• gnupg:
  • minor fix for MacOS X "Tiger" (quite old) with GCC 4: T5630
  • fixed Ed448/X448 v5 key in: T5609
  • fixed v5 key and signing in: T5628: v5: verify with signing sub key
  • fixed AEAD packet handling: T5584: gpg --list-packets lists wrong packets
    • I think that it can be backported to 2.2
• libgcrypt pkey branch: experiments for considering T4894
• pinentry: Solaris and the terminfo entry "xterm": T5631: pinentry-curses on OpenIndiana (Illumos distro) doesn't display correctly
• Solaris: T5623: gpg2 hangs on many tasks on OpenIndiana (Illumos)
  • patch for clock_gettime is needed
• openpgp-dt meeting

This week:

• Fix needed: Gnuk Token emulation with PC/SC
  • because of USBIP protocol and use of libusb_bulk_transfer in libccid
• openpgp-dt meeting
• if needed, I can work for T2385: support more than 1024 fds. just only for GNU/Linux (not Windows)

In the original SuSE's patch, _gcry_pk_sign_md function gets data template as SEXP as an argument, and the implementation does decomposing SEXP to get hash-algo. (A user of the function needs to compose SEXP with hash-algo.)

For 2.3, when you use PC/SC, please use the disable-ccid option in your .gnupg/scdaemon.conf.

Another link: http://hea-www.harvard.edu/~fine/opinions/xterm-problems.html

@moony Just in case when it's color related problem, could you try to cut&paste the screen when pinentry should display a dialog box?

I found some links:
XTerm FAQ:
https://invisible-island.net/xterm/xterm.faq.html
Why not just use TERM set to "xterm"?
https://invisible-island.net/ncurses/ncurses.faq.html#xterm_generic
What $TERM should I use?
https://tools.ietf.org/doc/xterm/xterm.faq.html#xterm_terminfo

do you want me to open a separate bug report for the pinentry issue and reference this bug report?

Thank you for locating the bug for (1).

s2k-count matters when you import the key.

When I run the gpg-connect-agent, it starts the agent and then hangs without responding with the time:

It seems that there are some problems: https://bugs.python.org/issue35455