I can't see null pointer de-reference (you claimed) in [4/5].
Could you please elaborate?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 20 2021
IIUC, with libgcrypt in LIBGCRYPT-1.8-BRANCH (not yet released) and libgcrypt 1.9.3, the build process works well (the problem with SIP has been handled).
Apr 19 2021
In T5401#145379, @werner wrote:You can't use an EdDSA as subkey for encryption. Encryption is the default for a subkey unless you provide key usage parameters. Yes, we could flag this as an error, but I won't give it high priority.
Yes, this is an edge case very unlikely to be encountered. The odd thing is the generated "ed25519" subkey does somehow encrypt and decrypt without issue.
You can't use an EdDSA as subkey for encryption. Encryption is the default for a subkey unless you provide key usage parameters. Yes, we could flag this as an error, but I won't give it high priority. I would anyway suggest to use
Thanks, that was right in time for this weeks 2.3.1.
aheinecke: I agree, we should not port everything back just because we could do that.
Has been released with 2.3.0 and we better open a new task if problems show up with v5 key. I am pretty sure that there will be a few v5 key problems after they get in real use.
This has been released with 2.3.0 and no relevant problems have reported in the last two weeks, thus closing.
Apr 18 2021
t-link does not do antthing useful, anyway. I don't think it is justified to add dlopen stuff. Running real test is anyway a manual action; for a full test automation we would need to emulate all supported cards.
Apr 17 2021
the t-link test should dlopen scute.so in runtime rather than link against it in build-time.
Apr 16 2021
This has been fixed in version 2.2.16.
As of slibtool commit 9c5ba5eb, scute now builds out of the box. I'd still recommend taking the above into consideration, though.
For what it's worth, scute is in violation of gnu libtool's documentation. Building with gnu libtool:
(sorry, about my former comment, I only now realized that you did just that already in your original patch)
Updated:
diff --git a/configure.ac b/configure.ac index 53a343b..f496729 100644 --- a/configure.ac +++ b/configure.ac @@ -82,6 +82,7 @@ AC_PROG_AWK AC_CHECK_TOOL(AR, ar, :) AC_USE_SYSTEM_EXTENSIONS
I guess the strcasecmp (nl_langinfo (CODESET), "UTF-8") results in some overhead, so if we do that what about kicking in only if a truncation is really to happen.
Actually, calling do_touch_file when some error(s) are not good.
Let me fix all the things.
Sorry, I was wrong. It seems that GNU C library has a feature to avoid bad truncation.
Apr 15 2021
Ok, thank you. I think task can be closed.
I hope last amendment is the following, which can happen if the tty can be opened only for reading but not for writing:
--- a/tty/pinentry-tty.c +++ b/tty/pinentry-tty.c @@ -583,7 +583,8 @@ tty_cmd_handler (pinentry_t pinentry) if (pinentry->ttyname) { fclose (ttyfi); - fclose (ttyfo); + if (ttyfo) + fclose (ttyfo); }
gpg4win 3.1 has no full Unicode support. You may try to install the new GnuPG 2.3 version on top of gpg4win to fix this problem or wait until we have releases gpg4win 4 which will come with GnuPG 2.3.
Thank you.
We also need to release memory for points.
Please tell us more details on how we can replicate your problem. Which Windows version, any non-standard software installed, non-standard installation direcories etc. You may also provide the output of