- User Since
- Mar 27 2017, 4:48 PM (339 w, 5 d)
I guess we should add an extended API to set the filter.
Thanks for the report and the helpful suggestion. I was anyway about to change the time format but your suggestion is better.
I am not sure whether we need to fix things in kleo but at some places gpg uses atoi() to parse the seconds since epoch. This should be fixed because that is the way gpgme provides the expiry time. I will also look into the ISO date string parser.
Tue, Sep 26
Lot's of things changed in the meantime.
HKP keyservers are anyway out of fashion and thus we won't put anymore effort into his part of the code.
Lot's of changes since 2.4.
Eva and me tested this using our 2.2.42 release candidate on Linux and
on Windows and were not able to replicate your problem.
Mon, Sep 25
Actually, a GUI to maintain the keys in an LDAP would be helpful for many sites.
Instead of all the debug options, please use
From my practical expexperience, @ebo's suggestion will work best for me. The other thing I have seen is to not use -signed but to append the initials of the signers.
Thu, Sep 21
Wed, Sep 20
gpg -v -K does not require a pinentry. You can check this by adding debug-pinentry and log-file /some/file to the gpg-agent.conf - you should not see any pinentry invocation.
Tue, Sep 19
Mon, Sep 18
Well, even out new versions.gnupg.org uses a shorter hash. Better get that released asap.
Fri, Sep 15
I guess you need to wait until we do a new release. If your company relies on this software it might be a good idea to enter into a support contract as other do.
For Windows things are actually more complicate. It seems to be common practise of sysadmins to provide PAC files which are used to map URLs to proxys and to decide whether a proxy is to be used at all. Fortunately Windows provides an API to find the proxy for a specific URL. We should use this.
Wed, Sep 13
gpgconf --show-codepages ist just a debugging aid. We use the code pages only for output to the console. The problem we see here is about log messages and they are always send as utf8 to stderr or the pipe used instead - without any translation.
Tue, Sep 12
Mon, Sep 11
Fri, Sep 8
Was already with gpgme 1.21.0. Note that I used the done column but in future a milestone would be more useful than that catch all "done".
Also fixed for gnupg22
Thu, Sep 7
@ebo: I just a did a test build: gnupg-vs-desktop-3.2.0-beta178-x86_64.AppImage in my directory
This has been well tested during development and is thus ready for a release.
Wed, Sep 6
That should be easy on Unix but on Windows we have the nul nul: and iirc also /dev/nul.
We have a fix for now and thus I lower the priority. Given that EasyPG mimics the GPGME API we should here also use another pipe to convey the passphrase (e.g. for symmetric encryption).
I don't see a value to do this for 2.2 and introduce a regression with that.
@iklocker: Which gpg bug to you mean?
Seems to be solved in the current version (vsd 3.2.0-beta178).
It might actually be useful to have an random number API in gpgme. When we do that we can also add a way t search for random numbers with an upper limit in each octet.
Bugs goes back to 2002 where we stopped checking trust for keys without any signature. This was really useful but has this strange behaviour.
BTW, with one of the recent gpgme fixes we now get
$~/b/gpgme/tests/run-keylist --extern --verbose foo run-keylist: file /home/wk/s/gpgme/tests/run-keylist.c line 414: <Dirmngr> No keyserver available
which is what users (and kleopatra) expects.
Note that for vsd we also need to change our default configuration file. The new "none" value provides a better error message than the old default of assuming that the AD carries the keyserver (which it does not in practise).