Hi Werner,

@bernhard Sorry for the delayed answer, was on sabbatical.

Excellent thank you.

I won't anymore follow the path of first doing a test install. That is way to hairy in respect to "make distcheck". Change is already in my working directory.

Is that really required? Should we wait what the conlusion of the WG will be?

Bison used to be the de-facto standard yacc ;-)

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.)

On my new Windows 10 laptop I see a "Windows Hello for Business 1". Thus put everything with "Windows Hello" at the end of the list or skip unless a reader-port is set. IIRC there are device with "virtual" or "Virtual" in their name, they don't make sense for us either. I would also put devices with "SCM" or "Identiv" to the top of the list. In particular the substrings "SPR532" seems to identify the Identiv SPR332 which is what we use here and actualay a suggested reader for GnUPG VS-Desktop.

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

Please tell me reader names to skip.

Note that I'm referring to file based keys, not card based.

I tested this on 2.3, and it doesn't seem to be fixed. When adding an existing ECDSA subkey I don't get the option to choose whether to make it a signing or encrypting subkey. Instead it only allows me to choose an encrypting subkey.

Thanks for your findings. I recall that I read this in the announcement and cursed about this new tendency in GNU to break long standing APIs.

OpenPGP requires the P < U property and gpg does also. In some parts of the GnuPG we re-calculate the CRT parameters but not in these code paths. Right, a better error message would be appropriate. I'll turn this into a feature request.

Fix for this issue landed RNP master, and will be included to the RNP v0.16.0 release.
Within fix:

• new keys will be generated with correctly tweaked bits
• using secret key with non-tweaked bits would issue a warning
• CLI command --edit-key [--check-cv25519-bits | --fix-cv25519-bits] added, allowing to fix older key

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

Looks like yytoknum was removed from Bison in version 3.8: http://git.savannah.gnu.org/cgit/bison.git/commit/?id=1efe31185ff6b0bc22ff527098971bedf1ace5f4

Please ask on a mailing list etc. This is a bug tracker and pnly very few people are reading your report.

Danke -

As long as we can't replicate this, it does not make sense to keep this bug open. Please re-open it if you run into it again in a replicatable way.

Fixed in gpgex 1.0.8

Sure they don't get created - they are optional.

I did in fact check --status-fd before, but I'm not sure whether it gives me the information I wanted.

In that case maybe GetUserDefaultUILanguage. Thank you for considering.

Thanks for the info.

Please use the --status-fd interface. This yields all the info you need. An exit code is not distinct enough for such purpose and you need to check the status lines in any case. For scripting gpgme-tool or gpgme-json might be useful as well because they do all the nitty-gritty parts of using gpg correctly

Problem/Bug still persists in current version (gpg4win 3.1.16) --> reopen

sorry for a confusion. We do not plan to certify DSA so disregard the second part of the patch.

Sorry, I just discovered that I had to click on "Save All" in order for the file to be actually stored in the disk and then it works.

Here it goes...

Please hit "mostra de registro..." link in the blue box and show us its content (you may want to check that it does not show sensitive data)

Thanks for the log, however, I would suggest to use 3.1.16 and try again.

Do we really need to support DSA in FIPS mode? I mean standard DSA and not ECDSA.

There won't be any other 3.1 release - install GnuPG 2.2.32 on top of Gpg4win 3.1.16

Argh, sorry for bugging. Clearing comment out - I simply missed fact that my tests are run with random messages, so with 5% probability another password will be interpreted as 'good' for the first SKESK.

My experience on a Window 10 system (with Gpg4win 3.1.15 which has GnuPG 2.2.27) was, that removing the expired root certificate did not help with https://keyserver.ubuntu.com and the intermediate certificate was not in the windows store, so it could not be removed.

Sure.

Removing an intermediate cert from your local system doesn't help because any correctly configured server will send you all necessary intermediate certs together with the server cert. You'd have to remove the expired root certificate instead (see Workaround 1 on https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/). The problem is that this will break certificate verification for any servers that still use the old intermediate cert, e.g. keyserver.ubuntu.com.

And it shows

Thank you so much for your explanation.
I just want to try with older version. Because when I try to run

The LE web site has instruction on how to do this. However, it is complicated and depends on your system. The intermediate cert you listed is signed by the expired old root cert. If you remove this intermediate cert the other root cert will be found and we are done. The old LE certs had a 4 tier chain and the new one a 3 tier.
See https://dev.gnupg.org/rG341ab0123a8fa386565ecf13f6462a73a137e6a4 and https://letsencrypt.org/images/isrg-hierarchy.png

One problem I see is that keyserver.ubuntu.com delivers a problematic intermediate(?) certificate:

If there is no easy way to install a new version of GnuPG, e.g. for Gpg4win or for GNU/Linux distributions: It may make sense to have instructions for the workaround ready.

Works for me:

$ gpg --version
gpg (GnuPG) 2.2.27
libgcrypt 1.9.4-unknown
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

The usual procedure for downgrading is

1. Uninstall the currently installed version
2. Install the older version

You should never ever downgrade. What is the problem with the new 2.2.32?