- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 26 2021
Qt4 is no longer supported. Please use the previous released version plus commit rP2859eddfb0c9: qt: Fix build against Qt4 to build pinentry for Qt4. For everything else use 1.2.0.
Will only be fixed for 2.3 and that has already been released.
I tried applied the bulk of the patch to 2.2 but w/o reading the key creation time from the card. We don't have the supporting code for latter in 2.2. However this does not make sense. Users should switch to 2.3 if they needs this feature.
I have rather created D536 as IMO the timeout should be changed, not the documentation.
We need a more detailed bug report to evaluate your problem. Please tell us your Windows version, any special software installed on the system (if any), a step by step description how to reproduce the bug, and any other information which can help us.
I understand your problem.
Added a test, and tested with glibc 2.32 by manual editing config.h for USE_POSIX_THREADS_FROM_LIBC.
Works correctly.
Aug 25 2021
Okay, I close this as a keyserver infrastructure problem. Feel free tore-open if you get other infos.
Thanks fro the report. Unfortunately I am not able to reproduce this on our systems. It might be an issue with other software on your system or a problem in our code. This is the first such report and as long as we don't get reports from other users, we can't do much for you. Please try installing on a different system or if you can provide more information feel free to re-open this bug report.
Will do.
To fix this, rG48251cf9a7d3: gpg: Improve generation of keys stored on card (brainpool,cv25519). for GnuPG 2.3 should be backported.
Closing, as downstream ticket has been closed.
Fixed in libgcrypt 1.9.4.
Fixed in 2.3.2.
It must be fixed in 2.3.2. If not, please report.
Aug 24 2021
Line 1454 : if (!opt.pcsc_shared || app->card->cardtype != CARDTYPE_YUBIKEY)
need to remove || app->card->cardtype != CARDTYPE_YUBIKEY
t-fam.c: In function 'main':
t-fam.c:34:14: warning: array subscript 'struct arg_and_data_s[0]' is partly outside array bounds of 'unsigned char[22]' [-Warray-bounds]
34 | aad0->next = NULL;
| ^
t-fam.c:30:10: note: referencing an object of size 22 allocated by 'malloc'
30 | aad0 = malloc (offsetof (struct arg_and_data_s, arg) + 2);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t-fam.c:35:13: warning: array subscript 'struct arg_and_data_s[0]' is partly outside array bounds of 'unsigned char[22]' [-Warray-bounds]
35 | aad0->len = 2;
| ~~~~~~~~~~^~~
t-fam.c:30:10: note: referencing an object of size 22 allocated by 'malloc'
30 | aad0 = malloc (offsetof (struct arg_and_data_s, arg) + 2);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t-fam.c:36:15: warning: array subscript 'struct arg_and_data_s[0]' is partly outside array bounds of 'unsigned char[22]' [-Warray-bounds]
36 | aad0->flags = 0;
| ~~~~~~~~~~~~^~~
t-fam.c:30:10: note: referencing an object of size 22 allocated by 'malloc'
30 | aad0 = malloc (offsetof (struct arg_and_data_s, arg) + 2);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t-fam.c:37:18: warning: array subscript 'struct arg_and_data_s[0]' is partly outside array bounds of 'unsigned char[22]' [-Warray-bounds]
37 | aad0->print_fd = fd;
| ~~~~~~~~~~~~~~~^~~~
t-fam.c:30:10: note: referencing an object of size 22 allocated by 'malloc'
30 | aad0 = malloc (offsetof (struct arg_and_data_s, arg) + 2);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~For GCC 11, modified version of struct arg_and_data_s has an issue for x86_64.
Aug 23 2021
Actually, I think there's a way to make gpg_strerror_r more usable on its own. I previously said
I find it quite difficult to use strerror_r and gpg_strerror_r. With having to guess and retry to get an appropriate buffer length, a wrapper which dynamically allocates the string seems to be needed.
We should update jitterentropy to 3.0.2 or newer, which should be easier to get through certification, if we will go this way. From FIPS perspective, we should be fine with either going through getrandom only or with jitter entropy, but the bottom-line was that we should probably keep both as we do now.
From Stephan I got the following response to the allocation handler use case
I think the last user of random-fips was removed with rCed57fed6de1465e02ec5e3bc0affeabdd35e2eb7
Yes, it makes sense to remove it.
Oh yes, I was blind.
Here is the place:
https://dev.gnupg.org/source/gnupg/browse/master/g10/pubkey-enc.c$151
A cursory look doesn't show me where list->result is set to something else than -1. Can you give me a hint?
In GnuPG 2.3, the procedure of decryption has been changed;
It now collects all ENC_TO packet, keeping it to ->PKENC_LIST field, and then process ENCRYPTED packet with the list.
So it is related to code page. Screenshots may be more informative:
After several days of observation, after modifying the configuration file options , the problem has indeed been greatly alleviated.
For the use case of struct arg_and_data_s in gpgme, which may allocate zero-sized ARG[], it seems that GCC 11 interprets it as an invalid use.