Sat, Feb 22
Fri, Feb 21
Okay, we now have global conf files in master. The extra flags to ignore or force certain options will be added to libgpg-error.
Werner could you maybe at least check for an internet connection, I don't know how to do it on Linux but on Windows it's easy because windows has API for that.
Thu, Feb 20
Seems that the public key needed to be exported from the Linux side and imported on the Windows side. Once this was done, the rest of the key information is displayed under Windows for the gpg --card-status.
Wed, Feb 19
But searching on Keyservers is also in my opinion not a common use case for Kleopatra users.
and by that bypassing all key source tracking as done by gpg. In any case searching by name or mail address on a keyserver should not be done - at least not by a GUI tool as used by non experienced users.
I agree that this is a tricky problem, but it should really be improved.
The problem is not to check whether there is a connection but on how to decide whether something is a pool or an explictly added single keyserver and how often should we try to connect or read from it. Without marking hosts as dead the auto search features won't work well.
@Valodim probably not so much as dirmngr might behave differently and not mark hosts as dead.
The proper solution is of course to use pkill instead of killall. SCNR.
I can attest to the "growing bit of popular lore": Roughly half the support requests I get to firstname.lastname@example.org boil down to an exchange of "it just doesn't work with a 'general error' message" -> "try killall dirmngr" -> "that did it". I have heard similar stories from @patrick from Enigmail users, and more than once heard people applying poweruser trickery like "I just have killall dirmngr in my resume.d".
I can confirm that the problem is gone from a build from the master branch. It indeed retries the search.
Thanks for your info.
I'm will be using OpenPGP applet for the YubiKey NEO in a virtialized environment. This emulated card can sign new keys just as correctly. PINs are the default 12345678 for admin and 123456 for user.
Or your card has the key to certify and its fingerprint is: CB522FE0379DDF40A93400D7E4BC91FACDA9A65B
Simply, we need the output of gpg --card-status to identify which key is on your card.
Nope, that's all I had. I'll try to get some debugging info in an hour.
Please show us your card information. Does it have unrelated signing key?
I'm pretty sure. That's the actual output above. Once again, if I remove the smart card, gpg --clearsign starts to just work, without a need to specify --default-key.
Tue, Feb 18
Are you sure that you have only one secret key? (run: gpg -K)
edit gpg.conf and dirmgr.conf manually
rem proxy in dirmgr
insert https keyserver in gpg
With the fix of T4623, this bug is now fixed.
Fixed in master, using Libs.private support.
Mon, Feb 17
well, so far it`s win 10 with 3.1.11
The info from your report iis a bit scarce; we would need more to replicate this and also the version of the software and the OS you are running.
- Worked on smartcard things.
- Prepared for beta testing Debian packages at ftp.g10code.com
- Worked on a minor security bug
- The usual
- Packaged GnuPG master for Ubuntu 19.10 and buster.
- Started working on gpgcardgui, moving kleopatra code around to libkleo to have it more usable with little dependencies.
- Problem is there that the code relies on many commands in Kleopatra so I have to decide what to take. Ultimately the commands could go into libkleo, too so that I can use them from gpg4win-tools in GpgOL.
Fixed in master.
Yeah, this can be done.
- postpone the changes of scdaemon to avoid conflict
- Regexp branch for GnuPG
- create gniibe/regexp branch
- Three implementations of Henry Spencer's
- My choice is: the one in Jim Tcl
- write gnupg-devel about regexp branch: because it was Damien who put the test case
- scdaemon change
- start tax paper work of 2019 for my business
Sun, Feb 16
I already tried reinstalling gpg4win without first uninstalling it (I thought it might repair corrupt files) but now I uninstalled first and it is working again.
I searched through C: and D: and found it in D:\Programme\GnuPG\bin and in D:\Programme\Gpg4win\bin - both seem to be created by gpg4win. I'll try reinstalling, hopefully without deleting my private keys...
The DLL libassuan-0.dll was not found or the system somehow found.
Do you have other versions of GnuPG or Gpg4win installed? Please search the system for copies of the above mentioned DLL?
Sat, Feb 15
Fixed in master and 2.2