Reading compressed point (in keys) is supported (except for NIST P-224). When curve point is represented in compressed format, it is correctly interpreted now. So, for example, I think that with 1.9.0, gpgsm can handle certificate which uses compressed format in its curve point representation.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 12 2021
Jan 11 2021
Jan 8 2021
Jan 7 2021
What is the state of this bug? Reading is implemented - do we really need writing (maybe to support certain smartcards)?
Jan 6 2021
I wrote https://github.com/rupor-github/win-gpg-agent to simplify usage on Windows until this issue is resolved - it handles various edge cases on Windows.
Jan 5 2021
The C++, CL, Javascript and QT Bindings are all written by hand.
Hi Werner,
we do it for the other bindings as well. |
can you elaborate?
Given all the resources we had put on this Python bindings I'd suggest to bite the bullet and replace Swig by handcrafted bindings. More work but we do it for the other bindings as well.
I think we can close this one, right?
For the context of all subscribed parties I think Werner refers to what Hockeypuck is doing: https://lists.gnupg.org/pipermail/gnupg-users/2020-December/064441.html
Meanwhile there are simpler ideas and code on how to do only authenticated uploads. Thus lowering the prio.
Jan 1 2021
Actually this isn't really a special case when you want to migrate your existing ssh keys to gpg and import them. As stated in this guide https://opensource.com/article/19/4/gpg-subkeys-ssh-multiples, what you need to do currently is export the master key with its private keys, delete the imported ssh key from your keyring and then import your private keys again.
Dec 21 2020
Dec 18 2020
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.
Dec 16 2020
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 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 12 2020
Report on some testing using master:
Dec 11 2020
Dec 9 2020
I am affected by the same bug and the patch seems to work for me. Login via gpg-agent with ssh support is possible again, which wasn't before, since some openssh and/or gnupg update. Not sure.
Dec 4 2020
And I also did a backport to 2.2 :-) See rGa028f24136a062f55408a5fec84c6d31201b2143
In T2291#139821, @lopter wrote:if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?
Thank you for all the work! Does it mean that, if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?
Dec 2 2020
For linking the MSI installer we already need a windows host and a windows sign host. The binaries inside that package we also sign usign the signhost / signkey which can be included in an optional / custom sign.mk during the build process. By default the path to the included sign.mk is gnupg-vsd/sign.mk in the src repo. But that can be changed of course.
Nov 30 2020
Done.
Okay, I usually only keep hitting crl+w in that case. But I see the point when doing imports this can be annoying.
Nov 27 2020
Nov 26 2020
You are right, the new 3.4 cards support brainpool curves in addition to the nist curves.
If you mean OpenPGP Card v3 standard, no it did not support cv25519 ed25519, but some other curves up until v3.4. So if there is a specific specification bringing this feature, can you might refer to the specific version? Otherwise, I think this task is still valid.
I remember the problem being the card manufacturers that are not interesting in cv25519 (yet).
Support was added in version 3 card.
Nov 23 2020
As for renaming "Change Reset Code" to "Set Reset Code", what about "Change PIN" and "Change Admin PIN"? Should they also be renamed? If not, why not? Is there no default reset code? Is there a way to find out whether the reset code has already been set (in which case "change" would be more appropriate than "set")?
You write
This does not work.
Can you be more specific? What doesn't work? Which OS, which version of Kleopatra, what smartcard are you using?
I though about this too but we need to take care about the logging functions of Libgcrypt which are intertwined with nPth (clamp function of libgpg-error).
Nov 19 2020
{F1982353}
Thanks. I understand the situation. Basically, gpg-agent's computation is done by a single thread (in current implementation), although it accepts many requests simultaneously.
Nov 18 2020
In T5137#139066, @werner wrote:Note that you actually run 30 independent processes with gpg 1.4 but with gpg-agent there is just one process to handle the private key operations (decrypt). To utilize more cores you need to setup several GNUPGHOME with the same private keys.
In T5137#139064, @gniibe wrote:I think that it is not gpg-agent but pinentry which causes millions of futex syscall errors.
For interactive use case, pinentry may be the point of contention.
I might be wrong if your key is not protected by passphrase.If possible, please try adding arguments for gpg invocation: --pinentry-mode loopback --passphrase-file YOUR_FILE_FOR_PASSPHRASE
This can avoid the invocation of pinentry entirely.
Nov 17 2020
I change this to a feature request: Allow several processes to run public key decryption using the same set of private keys.
Nov 16 2020
Nov 15 2020
I know these troubles.
Nov 14 2020
Nov 10 2020
Thanks for addressing this in master.
The feature (better cross compiling) was done in master.
We close this bug report as "Won't fix" since it will never been applied to 2.2.
In newer releases of libgpg-error, libksba, libassuan, libgcrypt, npth and ntbtls, we updated corresponding *.m4, so that we can use new gpgrt-config program only. And gpgrt-config command supports cross compiling and multiarch libraries.
Nov 4 2020
Nov 3 2020
FWIW, --enforce-passphrase-constraints does already work for symmetric-only encryption since 2.2.21 (rGae8b88c635424ef3). Thus this bug is actually a feature request to have a separate set of passphrase constraints option for symmetric-only mode.
Oct 29 2020
Indeed we need to fix/enhance this to make testing of --quick-revoke-sig easier. See over at T5093
I recall that I had the same bug during development. Must have slipped in again - Good catch.
I have added support for this to gpgme (and gpgme++/qgpgme). See T5094.
By the way, --quick-sign-key after --quick-revoke-sig refuses to recertify the key. -> T4584
There is another problem: Even if the first certification was revoked, trying to add a new certification with --quick-sign-key fails because '"user id" was already signed by key ...'
I found a bug. To reproduce generate a new key, then sign it with another key and then try to quick-revoke the signatures. This fails with "Not signed by you."
On purpose. We actually allow user ids and gpg should somehow reflect this. As requested by you I changed it in the man page to what is suggested.
I've noticed an inconsistency between the command arguments in the man page and in the usage/error message.
Oct 28 2020
The backend part is ready. Someone(tm) now needs to add it to gpgme. Extending the sign key API might be the best solution.
I was already considering this. I bet some people will view it as a bug if it is possible to add something other than a fingerprint. I'll change it in the man page.