- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 13 2023
my Yubikey works, too, if I disable PIV. With enabled PIV:
On Windows we always use --status-fd=1 but with gpg it is not a problem because we use a differenrt fd for output.
Fixed by rGfcbb849c26e9: speedo: Fix regression due to switching from gcc 8.3 to 10.2 for zlib build.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.19.0.
Fixed in 1.19.0.
Fixed in 1.19.0.
Apr 12 2023
This problem was introduced by commit cf10c74bd9d5aa80798f1c0e23a9126f381b26b3. Perhaps that change should be backed out in the interim so that a portable fix can be considered for the original issue?
Unfortunately I can't replicate that with my Yubikey on 2.4.1. Tried several variant and with and without keyboxd. My Yubikey has PIV disabled but I doubt that this is the problem.
Test with GnuPG 2.4.1-beta76 failed with "error getting current key info: invalid name":
It is a bit complicated. Let me describe the situation.
The crypto profiles have been removed in Gpg4win 4.1.1
Actually Linux already returns ENOSYS on older kernels where there is no getrandom libc call. Thus returning ENOSYS if we don't have the libc version of that syscall (i.e. getrandom) in FIPS mode seems to be the Right Thing to do. My whole comment was about fips mode - it does not make much sense to enable FIPS mode if the system is not appropriate for it.
I see, your issue is with the use of getrandom for FIPS. I understand now.
ENOSYS is POSIX. My point is that: getrandom was introduced in Linux kernel with flags for particular purpose (differentiate use of /dev/random and /dev/urandom), but that feature has gone.
But, for FIPS behavior, RHEL and related OS use (possibly, some would say misuse) getrandom with GRND_RANDOM. This use is RHEL specific (not for other GNU/Linux). Use of getrandom is non-POSIX.
In T6442#169419, @gniibe wrote:Returning ENOSYS is too strict, in my opinion; It doesn't work for machines other than CentOS/Fedora/RHEL.
Returning ENOSYS is too strict, in my opinion; Because the code in question doesn't work for machines other than CentOS/Fedora/RHEL. For other machines, it would be natural to just rely on getentropy (rather standard call).
Apr 11 2023
In T6445#169394, @werner wrote:Indeed, this is not implemented. AFAIK, this feature was introduced by PGP 2 to support BBS systems. I would suggest that you use binary messages and implement the chunking at the application level.
The gpgme logs show that gpgtar is called with gpgtar [...] --status-fd 1 [...] --output - [...], i.e. fd 1 is used for status output and for the result output of gpgtar. This cannot work. To me this looks like a flawed implementation of _gpgme_io_pipe() resp. new_fd() in w32-io.c which happily returns 1 as FD on the first call.
What Werner wrote was also my thought. If getrandom is mandatory for FIPS, then it must not be possible to disable it silently.