In T5250#148131, @bernhard wrote:

BTW @kaie

Thunderbird cannot use anything requiring GPL in its default configuration, because Thunderbird wants to distribute a single MPL licensed package that includes all components that are required for OpenPGP.

Any pointer why, they have made that choice, though? A bundle of MPL and GNU GPL components is fully allowed by the licenses as far as I know.

For many years I was convinced that my secret keys are stored in an encrypted folder. The .keyring file was there, everything looked correct...

Using GPGME is probably the best way, even if gpgme-json might also work for some operations.

It's worth noting that this issue is particularly impactful for devices with small screens whose sizes cannot be changed. A Raspberry Pi with an Adafruit touchscreen would almost certainly have issues, for example.
This also applies to mobile devices. For context, I use Termux on my Android phone, and this issue manifests there. I can enter the passphrase for an existing key and decrypt/sign with it, but any attempt to create a new key throws me into the same loop that the OP describes. (Interestingly, this happens whether or not I actually supply a new passphrase.)
Since I am on a mobile device in this scenario, my terminal dimensions are 56x115. I'm not familiar with the implementation details of GPG, but is there any chance we could fall back to a single-line, sudo-style password prompt if pinentry fails (or have pinentry fall back to that internally if the normal mode fails)? That should work on terminals of just about any size.
(As an additional note, I've also tried flipping into landscape orientation, hoping that would increase my screen width sufficiently. However, my keyboard then occupies most of the screen, and I receive the expected error message, gpg: agent_genkey failed: Screen or window too small.)
EDIT: I'm running GPG 2.3.1 and pinentry 1.1.1.

ok i found it just add "trust-model always" in gpg.conf

ok i found it just add "trust-model always" in gpg.conf

now its importing keys but it dosent trust them do you know how to fix this?
gpg2 --verbose --no-secmem-warning --no-greeting --auto-key-retrieve --no-tty --batch --yes --status-fd=2 --encrypt --armor -u <key-id> -r <email> -r <key-id> --output -
gpg: using subkey <sub-key> instead of primary key <primary-key>
[GNUPG:] KEY_CONSIDERED <key-id> 0
gpg: using pgp trust model
gpg: This key belongs to us
gpg: data source: <keyserver>
gpg: armor header: Comment: <key-id>
gpg: armor header: Comment: Name <email>
gpg: pub rsa4096/<key-id> <date> <name> <email>
gpg: key <key-id>: public key "<name> <email>"
imported
[GNUPG:] IMPORTED <key-id> <name> <email>
[GNUPG:] IMPORT_OK 1 <key-id>
gpg: Total number processed: 1
gpg: imported: 1
[GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0
gpg: auto-key-locate found fingerprint <fingerprint>
gpg: using subkey <sub-key> instead of primary key <primary-key>
[GNUPG:] KEY_CONSIDERED <fingerprint> 0
gpg: automatically retrieved '<email>' via keyserver
gpg: <sub-key>: There is no assurance this key belongs to the named user
[GNUPG:] INV_RECP 10 <email>
[GNUPG:] FAILURE encrypt 53
gpg: [stdin]: encryption failed: Unusable public key

Hmm your log does not seem to indicate that the key is requested by GnuPG,
e.g. something like

rmngr[6077.5]: DBG: chan_5 <- KS_GET -- =bernhard@intevation.de

is missing.

OK, thanks for the explanation. But I think that the documentation should be slightly changed to say that the mapping is hardcoded. Otherwise, this may surprise users of different machines with different GnuPG versions (or in discussions between different users), who would see different behaviors when the mapping changes.

GnuPG 2.2.29 does not use keys.gnupg.net anymore. What it does is mapping keys.gnupg.net that is read from an (old) keyserver setting in the configuration files to a (hopefully) working keyserver. The documentation of gpg and dirmngr does indeed still mention keys.gnupg.net. The main problem with updating the documentation is that there isn't a good replacement for keys.gnupg.net and since keys.gnupg.net still works (via the aforementioned internal mapping) it is probably the best option for now.

For the evolution command i get:
2021-07-21 03:04:06 dirmngr[2421] listening on socket '/run/user/1000/gnupg/S.dirmngr'
2021-07-21 03:04:06 dirmngr[2422.0] permanently loaded certificates: 129
2021-07-21 03:04:06 dirmngr[2422.0] runtime cached certificates: 0
2021-07-21 03:04:06 dirmngr[2422.0] trusted certificates: 129 (128,0,0,1)
2021-07-21 03:04:06 dirmngr[2422.6] handler for fd 6 started
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> # Home: /home/<user>/.gnupg
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> # Config: /home/<user>/.gnupg/dirmngr.conf
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> OK Dirmngr 2.2.27 at your service
2021-07-21 03:04:06 dirmngr[2422.6] connection from process 2419 (1000:1000)
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 <- GETINFO version
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> D 2.2.27
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> OK
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 <- KEYSERVER --clear hkp://<keyserver>:8080
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> OK
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 <- WKD_GET -- <email>
2021-07-21 03:04:37 dirmngr[2422.6] DBG: chan_6 -> S SOURCE https://<domain> #the domain dosnt has a WKD service
2021-07-21 03:04:37 dirmngr[2422.6] number of system provided CAs: 143
2021-07-21 03:04:47 dirmngr[2422.6] DBG: http.c:request:
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> GET /.well- known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>
HTTP/1.0\r\n
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> Host: <domain>\r\n
2021-07-21 03:04:47 dirmngr[2422.6] DBG: http.c:request-header:
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> \r\n
2021-07-21 03:04:47 dirmngr[2422.6] DBG: http.c:response:
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> HTTP/1.1 302 Found\r\n
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'date: Wed, 21 Jul
2021 07:04:45 GMT'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'server: Apache/2.4.41 (Ubuntu)'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'location: https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'content-length: 347'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'content-type: text/html; charset=iso-8859-1'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'strict-transport- security: max-age=15768000'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'connection: close'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: ''
2021-07-21 03:04:47 dirmngr[2422.6] URL 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>' redirected to 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>' (302)
2021-07-21 03:04:47 dirmngr[2422.6] redirection changed to 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>'
2021-07-21 03:04:47 dirmngr[2422.6] DBG: chan_6 -> S WARNING http_redirect_cleanup 0 changed from 'https://<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-host>' to 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>'
2021-07-21 03:04:57 dirmngr[2422.6] DBG: http.c:request:
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> GET /.well- known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>
HTTP/1.0\r\n
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> Host: [http://www.<domain>\r\n]www.<domain>\r\n
2021-07-21 03:04:57 dirmngr[2422.6] DBG: http.c:request-header:
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> \r\n
2021-07-21 03:04:57 dirmngr[2422.6] DBG: chan_6 -> S PROGRESS tick ? 0 0
2021-07-21 03:04:57 dirmngr[2422.6] DBG: http.c:response:
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> HTTP/1.1 404 Not Found\r\n
2021-07-21 03:04:57 dirmngr[2422.6] http.c:RESP: 'date: Wed, 21 Jul
2021 07:04:55 GMT'
2021-07-21 03:04:57 dirmngr[2422.6] http.c:RESP: 'server: Apache/2.4.41

i dont have one what shoud i put in it

i dont have one what shoud i put in it

Tried it myself, getting the pubkey seems to work here.
Debian gnupg Version: 2.2.27-2~bpo10+1

Yes same result

Did you try "--auto-key-retrieve"?

The comand that works says:

This is a duplicate of T5522: gpgme: qt: t-various.cpp TestVarious::testSignKeyWithExpiration fails on 32 bit.

Can you show the output of the command that works and the command that does not (and gets called by evolution),
please also add a "-v" to the options.

This key server also dosnt work

It could also be a problem of the keyserver (some hagrid instances are known to deliberately break RFC4880), can you try with a different keyserver, e.g. http://keys2.andreas-puls.de/.

Forgot to mention one thing: after changing my user folder directory I lost all my Outlook contacts. I was able to recover them... make sure you have a backup before attempting this!

I went through the patches above + what I suggested in previous comments, tested everything against both upstream and libgcrypt in Fedora in FIPS mode. There were slight differences, some cases were already fixed in master, some needed to upstream some of our changes, but the result is 10 patches working in both FIPS and non-fips mode, hopefully enough annotated. If not, please, ask for clarifications.

I just had the same issue as hurui200320. My user name contains a "ç" and Kleopatra did not start. The Windows event logger reported a crash in libstdc++-6.dll. This was with gpg4win-3.1.16. Installing gnupg 2.3.1 did not change anything.

I went through the OpenSSL drafts. The module boundary in OpenSSL will be separate fips.so object and only non-deprecated functions of OpenSSL 3.0 will be FIPS compliant. There is a global state, that will allow only approved algorithms and modes and there will be API to query the FIPS mode status using OSSL_PARAM_get* functions, but we still have some unknowns so I hope we will know more on the next meeting.

Just FYI, NSS offers following API:

rM6a79e90dedc19877ae1c520fed875b57089a5425 looks good

I was so far testing with changes on top of our patches.

With `/etc/gcrypt/fips_enabled/', make check fails by:

Update: still ./basic --fips fails (for me), because of GCM (18 errors).
Need to fix T4873: Enable AES GCM in FIPS mode.

That crcalgo can be any digest algorithm and SHA256 seems best option to me.

Thank you for checking and for revised patch. I tested your patch and it works fine for the basic test up until this failure with the crcalgo:

basic: algo 316, crcalgo: 3, gcry_md_open failed: Invalid digest algorithm
basic: algo 317, crcalgo: 3, gcry_md_open failed: Invalid digest algorithm

These are GCRY_MD_SHAKE128 and GCRY_MD_SHAKE256, but the md used here is actually GCRY_MD_RMD160 which is hardcoded and not allowed in FIPS.

That reminds me that we we should replace libgcrypt's internal debug functions by those from gpgrt. We have a dependency for gpgrt anyway and thus we should avoid code duplication. Sure we will keep the existsing public functions but that is easy given that gpgrt comes with gpgrt_logv since 1.28 which we can make mandatory (currently libgcrypt requires 1.27 (from 2017, with 1.28 is from 2018)

I applied rC297d31294333: tests: Fix messages to STDERR when FIPS mode is enabled.. Please note that your intention to change check_digests is right, but your patch actually didn't; When a MD algo is not supported, gcry_md_test_algo returns != 0 (an error code), and it "continues" to next entry (before the change).

Thank you for your report.

With the planned new context aware pubkey functions we technically could do this change w/o an ABI break.

Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program:
https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

It is a matter of the used font. 2.2.29 will fix this problem.

In T5510#147840, @catenacyber wrote:

Got a new bug with regression range ccfa9f2c1427b40483984198c3df41f8057f69f8:6dfab8cfb94ccb485a15b13df3c499cbb06fddf2

curve=23 secp256r1
point=04555555ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff73a865e2e128733884fb82ce625ade822f7d8a59a4dcc09266966cf1bf082856
bignum=2020ff2020202020202020202020202020202020202020202020202020202020
nettle: 0 045549408909dd3e772d7d669f8fba2248d334b54be3d18833223d944a328948c76198ac3b29712256dcd9ce1a09471f04267684e1edd45910d61d0b7847db2d58
gcrypt: 0 047a6ec0df23082c8ce54c2b536d76b30464f4e1e690bb77665d298f05f0bee6806e7db3377141cc71ee30dcb8ffb7240bc3ecf29132ab5eb4ae03c067cea0d561

Got a new bug with regression range ccfa9f2c1427b40483984198c3df41f8057f69f8:6dfab8cfb94ccb485a15b13df3c499cbb06fddf2

Same error message in Windows 8.1 x64 with the commands:
gpg --local-user 0x12345678 --sign-key 0xABCDEF12 or: gpg --default-key 0x12345678 --sign-key 0xABCDEF12.

Thanks a lot.

The original idea with the DNS code was just to source copy it but it turned out that we need to maintain it in GnuPG. Thus adding support for SHA256 makes sense to keep the code current in case we ever need to use it.

P192, P224, P256 and P384 are affected.

Is secp192r1 only curve that is giving wrong results?

Attached patch should fix the issue:

Thanks for reporting. There is two commits in that commit range, including https://dev.gnupg.org/rC9d909cb67e70fd792926ac1e2ab305b2cc96bc27 which adds fast reduction for NIST curves. So obviously something is wrong there. Is secp192r1 only curve that is giving wrong results?

Thanks for the report. Fixed.

Thanks for the report.

Needs to be tested with the current 2.2 version and a gcry_log_debugsxp should be added to the error output.

This will not be fixed. Brainpool is a standard feature of Libgcrypt and thus this is a bug in the used Libgcrypt installation. Note that although I recently fixed a new regression test for this case, I do not think that it is a good idea to add extra code for a broken Libgcrypt.

That might depend on your pinentry version. With a pre-1.1.1 pinentry and 2.2.28 I get this: