- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 18 2020
Ahh, there's a separate unblock command for the non-admin.
"unblock and set a new PIN" might not be the best description given that we have an "unblock" command to let the user unblock the own PIN using hist reset code. But yes, it is expected that it asks for the Admin PIN.
Werner, please retest. If "Change Reset Code" still doesn't work for you, then please answer the questions in the first comment.
Note: Officially, Kleopatra does not support OpenPGP v1 cards. At least, according to the text that is displayed if no card is found.
"Change Reset Code" should work in Kleopatra. At least for OpenPGP v2+ cards. Kleopatra simply does "SCD PASSWD --reset OPENPGP.2", i.e. the same as gpg-card. I have verified that it works with a Yubikey.
For support please use one of the community resources (see gpg4win.org) and read the manula (compedium) or one of the hundreds of HOWTO floating in the net.
Yes, makes sense. Although, you should use datalen = indatalen; in the last line (to prevent typos in the numbers).
IIUC, for completeness, it would be good to add the lines like:
Dec 17 2020
Dec 16 2020
Ready for testing.
I cannot find good test vectors for PBKDF2 with HMAC-SHA-2.
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!
If your problem is the incompatibility between standard OpenSSH (server) and PKIXSSH (client) for use of ssh-agent emulation of gpg-agent with ECDSA key, I'd suggest to apply following patch to your PKIXSSH:
diff --git a/compat.c b/compat.c index fe71951..0c9b1ef 100644 --- a/compat.c +++ b/compat.c @@ -245,7 +245,6 @@ xkey_compatibility(const char *remote_version) { { static sshx_compatibility info[] = { { 0, "OpenSSH*PKIX[??.*" /* 10.+ first correct */ }, { 0, "OpenSSH*PKIX[X.*" /* developlement */ }, - { 1, "OpenSSH*" /* PKIX pre 10.0 */ }, { 1, "SecureNetTerm-3.1" /* same as PKIX pre 10.0 */}, { 0, NULL } }; p = xkey_compatibility_find(remote_version, info);
Dec 15 2020
Ready for testing
Our tests are now in tests/basic.c.
For CMAC tests, we would need to use newer test vectors.
Dec 14 2020
Unfortunately and confusingly, PKISSH returns "OpenSSH" when asked by "ssh -V".
Please install real OpenSSH, if this is the case for you.
Quote from IRC:
hey, i've some problems with my smartcard since quite some time. i'm not sure whether it's openssh related or gnupg. it's a openpgpcard v2.0 and i have to workaround ssh logins by using "SSH_AUTH_SOCK=0 ssh ...". .gnupg/gpg-agent.conf -
gpg --edit-card and --card-status works fine and sign/encrypt works fine as well. only ssh auth fails
openssh 8.1_p1, gnupg 2.2.20
Yeah but it seems to be the same issue / reason. I wasn't aware that PKISSH is something else. I thought it was an extension/protocol or something
I added "Feature Request", because this is a request to support:
- A feature of bug compatibility, which is implemented wrongly in PKISSH
- for a specific algo of key, which is not considered so useful (== ECDSA)
- PKISSH, which is variant of OpenSSH
In T4563#140184, @idl0r wrote:I was and I am using OpenSSH on both sides, client and server.
I was and I am using OpenSSH on both sides, client and server.
I do not think that we should support a fork of openssh right now. If we would support it we are bound to maintain that for years - this is not a good idea.
Well, I have no idea about the technical background to be honest but without this patch it doesn't work at all for me, unless I stop using the agent or workaround it by using SSH_AUTH_SOCK=0. With this patch, I can use the agent again. I don't know how many others are affected by this but it made it usable again, which wasn't the case for months already.
In theory, I don't think the patch gnupg.patch works. It just ignore the flag.
In T2291#140172, @gniibe wrote:Thank you for testing.
For the issue #1, I think it is the probelm of rG1cd615afe301: gpg,card: Allow no version information of Yubikey.. This was introduced by the support of PIV feature of Yubikey.
Thank you for testing.
For the issue #1, I think it is the probelm of rG1cd615afe301: gpg,card: Allow no version information of Yubikey., which is fixed already. This was introduced by the support of PIV feature of Yubikey.
Dec 13 2020
Dec 12 2020
Report on some testing using master:
You're right. Thank you.
Oh, any chance GPG could inform the user when using export-pka that it is dead/deprecated? Also thanks for the quick reply.
PKA is dead but anyway: What you see is a record from a DNS zone file which has a specific semantic. The 14 for example means that 20 bytes follow.