This is better name. My point was that if we ever use that to create such a field the developer should not assume that arbitrary REs can be used here. We need to have some practical value here and I would prefer to see only the domain name. However, OpenPGP allows for arbitrary REs and thus we may see them here. This is problematic but we can't do much about it.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 6 2021
Well, all I can say is that
./run-genkey --loopback "elektra testkey (gen-gpg-testkey)"
creates a key without any problems and without asking for a passphrase. Even, if I add the GPGME_CREATE_NOEXPIRE flag to the call of gpgme_op_createkey. At least, from a terminal.
That would required that we also add an option --enable-ccid-driver - better tell the macOS folks to put diable-ccid-driver into /etc/gnupg/scdaemon.conf
FWIW, I think that it is a Bad Thing to use unreleased stuff from 1.8 for Debian packages. Only released versions sshould be used or patches we explicitly made to fix a bug. At the very least Andreas should have asked upstream whether this commit should be used for Sid.
Also fixed in version 1.8: rCbd662c090bd4: ecc: Fix the previous commit.
Note that the handling e part uses standard MPI in 1.8 (while it is done by opaque MPI in 1.9).
Or... we could add --disable-ccid-driver as default for macOS.
If it is built with LIBUSB enabled, please try adding the following to your scdaemon.conf:
disable-ccid
May 5 2021
Thank you for your response! I tried out all variants of gpgme_pinentry_mode_t and implemented a passphrase callback (using gpgme_set_passphrase_cb as suggested). It turns out that the callback is not invoked at all. However, if I switch back to gnupg 2.2.27, the callback is being invoked and the key is being generated (using the passphrase specified by the callback, as expected).
The problem might be that gpg tries to ask for a passphrase which fails on the CI. Try setting a passphrase callback and setting the pinentry mode to loopback. See https://dev.gnupg.org/source/gpgme/browse/master/tests/run-genkey.c$435.
Thanks for testing. I hope to get 2.3.2 out in two weeks.
May 4 2021
After upgrade:
Added documentation for the new fields.
- Renamed trust_regexp to trust_scope.
- Use part of _unused for storing trust_depth and trust_value.
May 3 2021
Thank you for taking time to look into that. There are couple of issues in the CAcert bug tracker talking about the same issue but if, (I see right), the certs still miss the usage flags:
RFC-5280 states in 4.2.1.3 for Key Usage:
The error code is: No Readers Available. With the latest version you should have seen that string.
Meanwhile we did some more tests on Windows and so you many want to try our betas at
I had a similar issue in Windows 10 too. In my case, the issue occurs only when my home path has non-ASCII characters. After I changed home path it works well.
Any chance looking into this @werner?
In T5359#145741, @werner wrote:Can you please clarify this point: If you run on Unix with --disable-ccid-driver, do you get the same behavior as on Windows?
Can you please clarify this point: If you run on Unix with --disable-ccid-driver, do you get the same behavior as on Windows?
I'm referring to this: https://www.gnupg.org/howtos/card-howto/en/ch02s03.html
@colemickens We don't maintain any ccid udev rules in GnuPG. What do you refer?
May 2 2021
May 1 2021
Apr 30 2021
To note, this is in contrast to my experience with gpg-2.2 (provided by gpg4win). With gpg-2.2, I was reliably using my Yubikey for a variety of things, and it handled hotplugging perfectly, as one would expect.
I have disabled this on Windows. Once "SCD DEVINFO --watch" works reliably on Windows, we can reenable the DeviceInfoWatcher on Windows.
Also let me know if there are any daemons I have to kill/restart when switching between GnuPG versions by changing the $PATH. Whenever I have problems with my YubiKey, I run gpgconf --kill gpg-agent, which I also executed when I switched from version 2.2.27 back to 2.3.1 but I have no idea whether this is required or sufficient.
$ gpg --version gpg (GnuPG) 2.3.1 libgcrypt 1.9.3 $ gpg --debug ipc --card-status gpg: reading options from '/Users/user/.gnupg/gpg.conf' gpg: reading options from '[cmdline]' gpg: enabled debug flags: ipc gpg: DBG: chan_3 <- OK Pleased to meet you, process 15218 gpg: DBG: connection to the gpg-agent established gpg: DBG: chan_3 -> RESET gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION ttyname=/dev/ttys007 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION ttytype=xterm-256color gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION lc-ctype=en_US.UTF-8 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION lc-messages=en_US.UTF-8 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> GETINFO version gpg: DBG: chan_3 <- D 2.3.1 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION allow-pinentry-notify gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION agent-awareness=2.1.0 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> SCD GETINFO version gpg: DBG: chan_3 <- D 2.3.1 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> SCD SERIALNO gpg: DBG: chan_3 <- ERR 100696144 Operation not supported by device <SCD> gpg: selecting card failed: Operation not supported by device gpg: OpenPGP card not available: Operation not supported by device gpg: secmem usage: 0/32768 bytes in 0 blocks
Run gpg --debug ipc --card-status to quickly see the communication with the scdaemon.
Hi Ingo,
Apr 29 2021
Can you help me, please?