- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 24 2021
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.
Aug 22 2021
Fallout from the fact that the @cbiedl left us and had an internal non-tagged ticket left open (T5456)
I see whats going on. The GitHub gpgme mirror (https://github.com/gpg/gpgme) is no longer updated. The last commit is from June 22, 2021. Changing the source link to the official (https://dev.gnupg.org/source/gpgme) URL gets the latest updates, and now builds successfully.
Aug 21 2021
This has already been fixed with rM4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e
Frankly, I don fully understand your report. Can you please clarify?
Note that with 2.2.8 we introduced full Unicode support on the command line. If you see scrambled output you may want to "chcp 65001" to get the output correctly rendered.
Aug 20 2021
I have recently been busy with the new features and mechanisms of the GpgFrontend project.
iirc Uli Drepper added a hack to dladdr which we made use of. Seems to be integrated into dladdr1 now.
In T5436#148656, @cnp1234 wrote:I added "disable-application piv" to ~/.gnupg/scdaemon.conf and the behavior went back to pin caching working as before. Since I don't use PIV, this is an acceptable workaround for me.
While I don't know if runtime integrity check is required or not by FIPS 140,
I checked OpenSSL, and it has such a check in openssl/providers/fips. The FIPS module configuration file which has the module checksum by HMAC is generated by openssl fipsinstall command.
Ah... I realized that HMAC integrity check with dladdr (using address of constant string) might work (at some point) to determine the filename of libgcrypt.so, when/if glibc implementation allows searching with address of constant string. So, my claim "never worked" was wrong.
Aug 19 2021
I have added shortcuts to the checkboxes and the (first) visible filename requester. I have not added shortcuts to the two buttons because the first one is anyway the default button, i.e. it reacts on Return, and the Cancel button reacts on Esc.