Re: Agent forwarding issue

Hi, Werner Koch via Gnupg-users wrote: > On Fri, 5 Apr 2024 13:03, Todd Zullinger said: > >> In such a case, it sounds like it may be reasonable to use >> the normal socket? Until the remote side is updated to > > In fact, I also did this for some time but later came up with > >

Re: Agent forwarding issue

Bee via Gnupg-users wrote: > In the mean time, you could put something along the lines of: > > {CmdCalls ; } 2>&1 | grep -v -e "^gpg: problem with fast path key > listing: Forbidden - ignored$" or something, to keep that output out > of your stderr stream. I think there's a downside to that (but

Re: Agent forwarding issue

Hi Werner, Werner Koch via Gnupg-users wrote: >> gpg: problem with fast path key listing: Forbidden - ignored > > I'll suppress that message in --quiet mode for the next release. Excellent, thanks! > When doing a secret key listing (which happens with -K but also in > --with-colons mode)

Agent forwarding issue

Hi, I have been working on setting up agent forwarding¹. One issue which I have not yet found a solution for is that gpg prints the following to stderr when performing actions involving the agent: gpg: problem with fast path key listing: Forbidden - ignored Both hosts are running

Re: 32768-bit key

Robert J. Hansen via Gnupg-users wrote: >> I don't know that there's anything to file a bug about. I >> don't see any non-rsa4096 keys on the Tails website: > > One of their certificates has a Curve-25519 subkey. I wonder if that's what > the original poster saw, and mistook it for being a

Re: 32768-bit key

Robert J. Hansen via Gnupg-users wrote: >> The TailsOS team has a key that's wy over 16384-bit. > > I suggest filing a bug report with them and asking them why they ignore the > best practices of cryptography. I don't know that there's anything to file a bug about. I don't see any non-rsa4096

Re: [Announce] GnuPG 2.4.1 released

Werner Koch via Gnupg-users wrote: > On Fri, 28 Apr 2023 11:21, Todd Zullinger said: > >> It seems neither of these files have not made it to the >> server yet: > > Sorry for that. I have used a new build machine and obviously forgot > one of the last steps. Most of the release process is

Re: [Announce] GnuPG 2.4.1 released

Hi, Werner Koch via Gnupg-users wrote: > Getting the Software > > > Please follow the instructions found at or > read on: > > GnuPG may be downloaded from one of the GnuPG mirror sites or direct > from its primary FTP server. The list of

Re: gpg: can't handle public key algorithm 18

Mike Schleif wrote: > Yes, I see that. > > However, our public key was generated by our GPG; and this file is > encrypted with our public key, since there is NO missing "secret key" error. > > Why, then, the subject error message? Perhaps the file is signed by an ECDH key? I can only guess.

Re: gpg: can't handle public key algorithm 18

Mike Schleif wrote: > $ gpg --version > gpg (GnuPG) 2.0.22 > libgcrypt 1.5.3 > > $ cat /etc/system-release > CentOS Linux release 7.9.2009 (Core) Algorithm 18 is ECDH, which is not supported by gpg on CentOS 7. You can confirm this in the Pubkey line of the gpg --version output: $ gpg

Re: Difference between versions--Question

K S via Gnupg-users wrote: > It would be helpful to know why I can't get compression in my build. I've > tried to build from source three times now. > > There are so many packages in Ubuntu with zip, zlib, and bzip2 in the name > I can't begin to try them all. I've looked at config.log and it

Re: GnuPG 2.2.36 released

Bernhard Reiter wrote: > Am Montag 11 Juli 2022 14:50:24 schrieb Konstantin Ryabitsev via Gnupg-users: >>> See https://dev.gnupg.org/T5949#159890 for why it doesn't work for you. >> >> Ah, okay, that's unfortunate. I guess I'll skip this release, since I can't >> verify it without building gnupg

Re: Error importing fetching key from wkd

Konstantin Ryabitsev via Gnupg-users wrote: > FYI, I also provide gnupg22-static and gnupg23-static packages that can be > rebuilt and installed on RHEL 7+ (though I haven't tried on RHEL9): > > https://copr.fedorainfracloud.org/coprs/icon/lfit/packages/ > > They install into /opt and can be

Re: Error importing fetching key from wkd

Hello again, I wrote: > Dirk Gottschalk via Gnupg-users wrote: >> A workaround for this is to download the SRPM, remove the >> line '--disable-brainpool' and rebuild the package. > > Ahh, excellent. That's a relatively recent change. It's > available in the Fedora (and RHEL) libgcrypt-1.10

Re: Error importing fetching key from wkd

Hi, Dirk Gottschalk via Gnupg-users wrote: > A workaround for this is to download the SRPM, remove the > line '--disable-brainpool' and rebuild the package. Ahh, excellent. That's a relatively recent change. It's available in the Fedora (and RHEL) libgcrypt-1.10 packages which I believe are

Re: Error importing fetching key from wkd

Hi, Werner Koch via Gnupg-users wrote: > On Wed, 25 May 2022 22:58, Dirk Gottschalk said: > >> $ gpg --with-colons --list-config curve >> cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;secp25 >> 6k1 > > This should read > >

Re: Odd error

Hi, Werner Koch wrote: > I looked at the Fedora Libgcrypt source and noticed that they ship > libgcrypt with the nistp192 and all brainpool curves removed. I have > not yet build this version but given that one of your keys has brainpool > curves this might be the culprit. > > I can understand

Re: setrlimit failure on aarch64 (was: Interesting failure on aarch64)

Werner Koch via Gnupg-users wrote: > On Fri, 20 Dec 2019 11:22, Konstantin Ryabitsev said: > >> On x86_64 this succeeds, but when I tried building on aarch64, that step > [...] >> gpg: Fatal: can't disable core dumps: Operation not permitted > > setrlimit returns an unexpected error code: >

Re: Interesting failure on aarch64

Hi Konstantin, Konstantin Ryabitsev wrote: > I came across an interesting gpg failure while trying to build > git-2.24.1 RPM for Fedora COPR. As part of RPM build, the prep stage > attempts to verify the tarball signature using Junio's PGP key: > > %prep > # Verify GPG signatures >