Sorry, it was simply my confusion (between GEMPC_PINPAD and GEMPC_EZIO).
Fixed now.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 29 2019
Oct 28 2019
Please test. When I can confirm that it is stable, I'll backport it to 2.2.
Oct 18 2019
Or... it could be a feature, not bug, so that failure of -e -r someone can be examined by --locate-keys someone.
Let me clarify the point.
Oct 17 2019
I think that we should apply further change:
diff --git a/g10/getkey.c b/g10/getkey.c index 077209415..1c337149c 100644 --- a/g10/getkey.c +++ b/g10/getkey.c @@ -1369,7 +1369,7 @@ get_best_pubkey_byname (ctrl_t ctrl, enum get_pubkey_modes mode, *retctx = NULL;
I found more wrong cases of get_best_pubkey_byname.
For ranking results,
(1) It may return non-encryption primary key as the most relevant key, when its validity is higher.
(2) It may not select encryption primary key even if its creation time is newer.
Oct 16 2019
I also think this makes the most sense.
In my opinion, --locate-key should locate encryption key.
Oct 15 2019
@gniibe oh, I see thanks for pointing out precisely main the problem. I will check the hardware supply chain RoHS 2002/95/EC
There are some problems with the definition of --locate-key. Further discussion required.
@pow, thanks for a reference. But problem here is that there are multiple products with same name.
Oct 9 2019
Oct 2 2019
I modified _gcry_ecc_fill_in_curve so that g_y has new value in eid4730.
Sep 28 2019
Jun 25 2019
Jun 3 2019
Mar 27 2019
gpg4win 3.1.6 is released which contains this fix.
Mar 7 2019
Changes backported to 2.2
Feb 27 2019
We also need to fix for encryption and signature in CSR.
Feb 26 2019
Builds fine now with GCC 9. Thanks for looking into this so quickly.
Fixed in master, by removing use of compound literals. Compound literals are not portable feature (even for C99 code), so, it's good to avoid when we can.
Still dns.c uses C99 features of struct initializer with name.
Feb 25 2019
Fixed in master.
Nov 5 2018
No more complaints thus time to close.
Nov 29 2017
If more fine-grained control is needed with suspend-to-ram, we need to write kernel driver for USB access.
I learned suspend-to-ram functionality. Currently, for Linux, if we have USB driver in kernel, there are methods to handle suspend-to-ram and resume events. For user space driver by libusb, there is nothing and it should all work well by reseting after resume.
Nov 14 2017
Tested with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 10 (64bit) with Outlook 2016.
Nov 13 2017
Jochen could you please test this on one of our test VM's again and resolve this then?
Oct 26 2017
Oct 24 2017
I am closing this bug report, as I can't get feedback to fix something.
Oct 20 2017
gniibe: Can you check the status?
2.0 reached eol in 2 months so need to check it. For 1.4 I assume it has been fixed ;-)
Aug 8 2017
Re-opening.
Aug 7 2017
I also have to add that, if this really has been resolved, it only covers up the case if the missing subkey(s) is/are on the smartcard(s), it does not solve the problem when none of the missing signing subkeys are in smartcards (as in, all on different computers). And it's clear that for version 2.1.22, it fails to get the available subkey on the disk for this case.
@gniibe: I've tested 2.1.22 (from Debian experimental) and, while gpg --sign works, other programs (eg: git tag -s) still prompt to insert the card of the first signing subkey, despite the card with the second signing subkey being present.
Is that expected?
Aug 1 2017
It's there in GnuPG 2.1 for a while, and bugs introduced by change were fixed.
So, I'm closing this bug.
@fogine , I'm afraid your comment is related to this bug particular report of T1983: gpg2 prefers missing secret key to available key on card.
And your problem cannot be replicated by my environment with 2.1.22.
If you still have the issue with 2.1.22, please open new ticket.
gpg (GnuPG) 2.1.21
libgcrypt 1.7.8
Jun 30 2017
I added a new task status "Testing".
Jun 29 2017
On Wed, 28 Jun 2017 15:47, noreply@dev.gnupg.org said:
What tests do you want to be done?
Jun 28 2017
What tests do you want to be done?
Given that we have no TESTING status, the only way I can handle this is by keeping the ticket open and add the TESTING flag. Closing a bug which has not been tested is a bad idea.
Jun 27 2017
@werner An open ticket should mean there is something that can be acted upon. Unless you are saying that we should actively look for regressions or should actively do more testing, this ticket should be closed now. There is plenty of peripheral information that will remind us of this ticket in case more issues resurface related to this change.
Jun 26 2017
Jun 23 2017
I have tested this and it appears to fix the leak of gpg-agent processes in virt-builder, thanks.
I commited a change which should fix this on Linux
This is such a large change that I feel uneasy to close the bug before we know that there are no regressions. This Means we need to wait whether the next release will break.
Jun 5 2017
May 23 2017
I applied another approach: rGfbb2259d22e6: g10: Fix default-key selection for signing, possibly by card.
Please test.
May 19 2017
Sorry, my fix was not good. Re-opening.
May 16 2017
Fixed in 2.1.21.
May 8 2017
This seems to work just fine on our archlinux box with the nsswitch configuration above.
Justus, will you please so kind and take care of this.
Apr 27 2017
Sorry, I was wrong. The patch also works for signing to key.
The impact is gpg frontend always asks gpg-agent for card key.
It involves invoking scdaemon and accessing to USB.
Apr 24 2017
Will be released with 3.0
Apr 4 2017
I don't have one of these systems handy to test with, but if the fix in dee026d7 does what it says it does, this sounds like it's probably OK to close in my book. if there are more problems, i'm sure we can re-open it.
Apr 3 2017
Time to say good bye my dear bug.
we are now at 2.1.20 - time to mark this one as resolved.
dkg: Can we close this now that 2.1.20 is out?
Fix is in 2.1.20
Mar 31 2017
Mar 30 2017
Indeed. We did not address the issues at all, we decided to skip all tests and
some fell through the cracks.
Unfortunately 1.9.0 doesn't address fully the issues:
[ 108s] Traceback (most recent call last):
[ 108s] File "./t-protocol-assuan.py", line 27, in <module>
[ 108s] err = c.assuan_transact('nop')
[ 108s] File "/home/abuild/rpmbuild/BUILD/gpgme-1.9.0/lang/python/python2.7-gpg/build/lib.linux-
x86_64-2.7/gpg/core.py", line 790, in assuan_transact
[ 108s] errorcheck(err)
[ 108s] File "/home/abuild/rpmbuild/BUILD/gpgme-1.9.0/lang/python/python2.7-gpg/build/lib.linux-
x86_64-2.7/gpg/errors.py", line 62, in errorcheck
[ 108s] raise GPGMEError(retval, extradata)
[ 108s] gpg.errors.GPGMEError: GPGME: IPC connect call failed
Two tests fail.
Mar 28 2017
1.9.0 has been released.
Mar 27 2017
As of 348da58fe0c3656e6177c98fef6b4c4331326c8e all Python tests are skipped with
GnuPG < 2.1.12.
Mar 24 2017
I concur. We should disable the Python tests for gnupg versions < 2.1.12 (which
is about a year old)
I've rebased the patches against 1.8.0 but I still saw 22 failing python tests
with 2.0.26
Master fails for me even harder with 36 tests failing.
The gpg-connect-agent call's fail because --agent-program is not supported. In
master we even have --debug-quick-random which is even more recent (but which we
would also need in random starved environments like build daemons)
My preferred solution at this point would be to just say for 2.0.x the python
tests are unsupported and disabled completely. All the problems are with our
agent setup regarding the test suite and not really with functionality.
Mar 21 2017
See tests/run-genkey --set-primary on how to use it.
commit 421ddd1 implements that for 1.9.0.
Mar 20 2017
Unfortunately I'm unable to test this properly, because the patches can't be
applied properly to 1.8.0 (I need to add them to the package).
FYI this is:
Skip tests if GnuPG is too old.
Use 'gpg-agent --allow-loopback-pinentry' if applicable.
Mar 17 2017
I marking this as resolved since I think the issue is fixed. If this is not the
case, please reopen.
I'm marking this as resolved since I think is fixed. Please reopen if this is
not the case.
Mar 3 2017
Thomas confirmed this, with our workaround for the SNI problem removed the
problem still occurs. We have activated our workaround again to keep wks working
on testkolab.
I think gniibe may have posted a related patch to gnupg-devel some time ago not
to abort on non fatal GNUTLS alerts but I don't think it was applied.
This issue does not have high priority for me so I downgraded to minor bug but
it's still an issue.
Mar 2 2017
Glenn: I'm not exactly sure why your scenario exposed this issue. I suspect
that it has something to do with you have never used this key for encryption
prior to the verification, but it would require more investigation to confirm.
Neal: Do you have an answer for him?
Mar 1 2017
Let's keep this one open to track missing options.