User Details
- User Since
- Mar 27 2017, 4:48 PM (416 w, 1 d)
- Roles
- Administrator
- Availability
- Busy Busy until Sep 9 2030.
Yesterday
Mon, Mar 17
FWIW: It does works when using GNUPGHOME instead.
This has always been the case. git blame shows for check_signatures_trust:
Fri, Mar 14
Done
BTW, do we really need a C++ API for this? Might make sense due to the need for a context.
Thu, Mar 13
Well, we also have the gpgme test suite which tests a couple of other things and for obvious reasons we need to keep this stable. Granted, sometimes we had to change the gpgme test suite as well. My personal preference would be your second choice.
Wed, Mar 12
I can't replicate your findings here . In a test directory w/o a gpg.conf:
Uihhh
Did you also tried with --no-sig-cache ? That could help to get a better insight into the reason for that difference.
Tue, Mar 11
Please test using the latest gpg4win installer (beta145).
The problem is that it may take really long to read the certificates form a card and some card applications even require to give a PIN for reading the certs. A background operation may thus surprisingly lock up the box
Mon, Mar 10
Fri, Mar 7
Thu, Mar 6
rG25d48663f9 seems to fix this for me. However in my test cases I got a hang in dirmngr simply by running several gpgsm instances to get the details of an X.509 key. I had different logging options enabled, though.
Please use "unbreak now" only for *released* software with a criticial bug.
Wed, Mar 5
master is development and you can't expect that it always build on all platforms.
Tue, Mar 4
We do not have an error code for Admin PINs. The Admin PIN is also an OpenPGP card specific termm and other cards use different terms. For example a NKS has no Admin PIN at all but an alternative PIN.
Wed, Feb 26
New API gpgme_op_random_bytes is now in master (gpgme 2.0). Use tests/run-genrandom --help for testing. Extra features will come soon.
Please try again. This was due to a change in the RBL we use. Might be fixed now.
Tue, Feb 25
Looks like scdaemon which I experienced today also but without having enabled scdaemon logging.
Mon, Feb 24
I don't see a bug here and any change in this domain disks a regression with existing data. BTW, the mode byte was not even part of the signed data before signature version 5.
My comment from a year ago still holds true; you may want to fix your testing framework and re-openig this bug iff you can show that there will be no regression with PGP 7 and later.
Fri, Feb 21
Also fixed for 2.4
This has been fixed in master with rG48978ccb4e: