$ gpg --card-status $ gpgconf --kill scdaemon $ git fetch << (Used my PIN, I have reverted to my previous code other day, is not anymore 123456)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 22 2020
Dec 21 2020
Thank you for your testing.
May I ask more test, please?
Dec 20 2020
Hi, I have applied both patch and appears Yubikey is now working correct. I have uploaded the log here.
Dec 16 2020
In T5167#140229, @gbschenkel wrote:Nice, I gonna apply the patch and see if resolves for me!
Nice, I gonna apply the patch and see if resolves for me!
Dec 10 2020
With my Yubikey NEO, when I use OTP (touching the button to generate OTP output as key input), I observed "card eject" event:
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: interrupt callback 0 (2) 2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: NotifySlotChange: 02 2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: card removed 2020-12-10 11:23:05 scdaemon[7254] DBG: enter: apdu_get_status: slot=0 hang=0 2020-12-10 11:23:05 scdaemon[7254] DBG: leave: apdu_get_status => sw=0x1000c status=0 2020-12-10 11:23:05 scdaemon[7254] DBG: Removal of a card: 0
Dec 9 2020
I checked the development log for the addition of:
libusb_clear_halt (handle->idev, handle->ep_intr);
In T5167#139966, @gbschenkel wrote:I have another yubikey neo but its clean. Can it help it?
I have another yubikey neo but its clean. Can it help it?
In T5167#139964, @gbschenkel wrote:Changing modes will I lose/change my OTP and FIDO codes?
Dec 8 2020
Changing modes will I lose/change my OTP and FIDO codes?
Following device (a bit older than yours, I guess) works well:
DBG: ccid-driver: idVendor: 1050 idProduct: 0112 bcdDevice: 0334
When I configure it to OTP+FIDO+CCID, it also works for me, it is:
DBG: ccid-driver: idVendor: 1050 idProduct: 0116 bcdDevice: 0334
Thanks a lot.
Let me explain the situation.
Dec 7 2020
Hi, I changed the PIN, killed the gpg-agent and scdaemon, edited the scdaemon.conf to include your instruction, after, I run the following commands:
Thank you for the information.
In the log, the driver detects removal of card wrongly.
That's the cause of this problem.
In T5167#139880, @gniibe wrote:Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?
Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?
Dec 2 2020
I could find no issue with the error handling for verify errors.
Dec 1 2020
In T5159#139739, @werner wrote:Put
extern char **environ;after the the include directives.
Put
extern char **environ;
after the the include directives.
After applying @gniibe 's patch:
The problem is that posix_spawn is not portable enough for libgcrypt. It is really time that we move the spawn functions from gnupg to gpgrt so that we can use them also in Libgcrypt.
BTW, I'm not sure if the claim in T5009#136688 is correct.
See also: https://dev.gnupg.org/T5009#136688
See my comment in: https://dev.gnupg.org/T5024#139701
Nov 30 2020
After disabling SIP, now all checks pass without having the library symlinked to /usr/local/lib. So it might be T2056: libgcrypt: make check fails "random" test on OS X 10.11 with link error after all.
After doing:
IIUC, for the build of Homebrew, it is the issue of in: https://github.com/Homebrew/homebrew-core/commit/e7da1e2157b2e8373c3b39ea6398f51588ea537c
Nov 27 2020
No more problems reported, so I assume like @aheinecke that it has been resolved in Windows.
Nov 24 2020
Please use shorter password.
For gpgsm, maximum is 31 chars.
Nov 23 2020
Nov 10 2020
Did you remove .gnupg entirely? Secret keys are stored in .gnupg/private-keys-v1.d. If it remained, you didn't import your secret keys.
If it was the case, I'd like to merge this report to T3391: cannot import subkey that was once marked to be on a card.
Oct 3 2020
Hello Werner,
Oct 1 2020
Aug 28 2020
Hmm. Now, even with a fresh session, dirmngr, GNUPGHOME not set, etc. it seems to work. It correctly uses the config file and the keyserver, and the logs show the Home and Config variables are set and communicated correctly.
Aug 27 2020
Aug 19 2020
I am the worst. I totally forgot about this.
No more information, can't proceed, thus, closed.
Jul 2 2020
Yes, it will fix the problem on x32, I suppose.
If it's difficult for dpkg, for some reason for now, workaround for gpgme packaging is disabling pie hardening for x32 until pie will be its compiler default.
For gpgme, it is only test binaries which matter (pie or not), so, the impact (for x32) is minimum.
Jul 1 2020
on #debian-dpkg on IRC, Guillem Jover suggested that we might want to fix dpkg specfiles to use +self_spec: instead of *self_spec:.
Some information of Qt5 about -fpic:
Debian's GCC build for PIE default: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules.defs#L1400
Here is my understanding. My point is it's not problem of gpgme. To fix it correctly, I think that dpkg should be fixed and it would be needed to fix Qt too.
I'm still not understanding what specifically should be fixed here. Sorry to be dense about it, but the range of options and configuration details that are different are pretty puzzling.
Jun 30 2020
I think that it is the problem of dpkg to override the compiler flag by the spec file. When compiler default is -fPIE, it works well. If not (for the case of x32), it fails.
In the past, hurd-i386 had same issue, but compiler default seems to be now -fPIE, thus no problem.
Thanks for your report.
May 19 2020
Parsing and creating of certs does now work. I was not able to find sample CMS objects so this part is not yet finished.
Closing with Info Needed.
May 8 2020
hello
thanks for the feedback
it s indeed exchange 2007 (migration planned on long term)
we will try the imap workaround
There was a similar Problem in the past reported on our mailing list:
Jan 2 2020
PS I forgot to say why movement to cmake will be the best way.
I totally disagree.
Please read libgpg-error's README. For each architecture we need to have a dedicated config file - this has nothing to do with autotools. Big and little endian variants are obviously different architectures. Here is an excerpt from the README
Jan 1 2020
Hello @wener, I want to say that libgpg-error is the only one (!) application that fails to cross compile using valid toolchains: "armeb-unknown-linux-gnueabi" and "aarch64_be-unknown-linux-gnu". It compiles and runs perfectly using "arm-unknown-linux-gnueabi" and "aarch64-unknown-linux-gnu", but fails with big endian. I see project are actually using "hton/ntoh" so we shouldn't see this error. What this problem is about?
Dec 6 2019
Oct 1 2019
Hi
FYI here is what I did to resolve:
running gpg.exe and gpg-agent.exe as Administrator and XP mode....
gp-agent:
set service Priority to REALTIME
Disabled Windows UAC virtualization.
Sep 27 2019
OK, I identify the problem.
Sep 9 2019
But this problem remains for several versions for some time. I tried to find out the source of this "new option" in the communication, but I could not find anything about "GPG Agent" in the source code of openssh.
Sorry for the late answer, but I have been busy. Actually this happened against several ssh versions, for some time now.
Aug 28 2019
For information, I can’t reproduce here, either with GnuPG 2.2.17 / Pinentry 1.1.0 or with a fresh build from the tip of the master branches. Both pinentry-tty and pinentry-curses prompt for the password as expected, independently of whether the file to decrypt is specified as an argument or sent through standard input.
Aug 21 2019
@dkg, I changed the title and adjusted the description to more accurately describe the situation.
Aug 20 2019
@skeeto can you edit the summary/title of this ticket to better reflect what you think the underlying issue is?
Aug 13 2019
Those changes make the script work for me, specifically passing the input as an argument and not through standard input. Digging more, it looks like the underlying issue is related to using pinentry-tty (my case) or pinentry-curses when passing the OpenPGP input via standard input. This causes pinentry to give up before prompting. For pinentry-tty it fails with "ERR 83886340 Invalid IPC response" and pinentty-curses fails with "ERR 83918950 Inappropriate ioctl for device".
Jul 23 2019
Thanks aheinecke and dkg.
I havent been able to replicate the fault using the command line (using the exact same command and options that our program is calling)
however our R&D dept have,
The next time it fails and we can replicate it we will try the --homedir fix and see if thats it.
Its the same user in the program and command prompt so we dont think its a certificate issue.
I'm also not sure how to classify this issue. I'm giving it low priority for now as we do not have the info to determine if this is a program error.
Jul 22 2019
Thanks for clarification.
However, CCID_CMD_TIMEOUT should be then based on BWT value reported by the card/reader, as bulk_in() function will still timeout if BWT is longer than 5 seconds.
Thanks for pointing me in the right direction. I was confused by the hard-coded timeout value and got it all wrong.
I realized that it's a product of token. Then, I suggest that implementing time extension correctly, if some operation doesn't finish in BWT (block waiting time).
In general, if it requires more time, a reader can reply with time extension.
What's Trustica Cryptoucan?
In general, if it requires more time, a reader can reply with time extension.
Jul 18 2019
All my keys are RSA 4096. It worked fine with OpenPGP smart cards and with two Yubikey 5. On all devices a set of RSA 4096 keys were geneated on the device itself. Only one card failed. But even the card which failed, generated at least the signature key in RSA 4096.
Please let us know what kind of key and how large, like RSA-4096 or ECC Brainpool.
For RSA 2048 or larger, yes, it takes too long.
Jul 12 2019
I disabled the dependency rules for the figures (it's only enabled for maintainers).
Jul 11 2019
Which SSH client are you using?
Jun 4 2019
May 16 2019
May 15 2019
It's complicated to have a good solution, because we need to change assumption (serial number identifies keys).
May 12 2019
Hello again - can I ask about the status? Or should I consider this as a no-fix? Anything I can assist with?
May 8 2019
As this update lists multiple issues and following fixes for them, maybe it was resolved by Microsoft?
May 2 2019
But sadly I can't see any problem with the mail. Looking at the source of the mail it has the image as one attachment. That attachment is displayed. There are no other attachments part of the mail and so other clients also only show that one attachment.