OK, I'll gdb in there to see what happens. My domain is a classic pgp.domain.com
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 14 2021
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).
Oct 13 2021
No, the error is harmless. I guess it shouldn't be printed (except when debugging).
Wouldn't it be safer to use gpgv for verifying the signature than to add a code path to gpg to circumvent the hard de-vs compliance check?
We now require a way to get the actual image of a process. For macOS the BSD method is used and we obviously need to find another way for macOS.
@rupor-github no problem for the delay. Thanks for explaining!
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 explained the context.
No, there is no discussion about this in the WG.
Oct 12 2021
Hi gniibe!
Thank you again.
The new bugs have been fixed in 2.3.3; see T5565.
Just adding this note because a next step I'm also evaluating in my current T5593 configuration status it to temporarily create a new Gpg4win 3.1.16 hybrid configuration by also adding latest GnuPG v2.2.31 to see if all issues I reported here are still present (which is also quite probable).
Also because of T5593 it would just be quite interesting to see if GnuPG v2.2.31 too might experience same T5593 path related error.
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.
Oct 11 2021
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
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.
Oct 10 2021
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