What about at least accepting env variables OR tilde expansions? That will make it easier to integrate with dotfiles that intentionally use a home-dir based executable without having to pass the full path, so it could work cross platforms.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 16 2022
Mar 2 2022
Jan 17 2022
In T5783#153879, @werner wrote:Sending a private key with just the local protection is not a good idea.
Sending a private key with just the local protection is not a good idea. It is better to export the key and then send it in an encrypted mail - for example in symmetric mode with a strong password.
Saw this again and the commit was not in the Stable 2.2 branch. I have cherry picked it. This should resolve this issue.
Jan 16 2022
Jan 15 2022
Nov 25 2021
Nov 23 2021
Nov 13 2021
Oct 13 2021
@rupor-github no problem for the delay. Thanks for explaining!
Oct 12 2021
@bernhard Sorry for the delayed answer, was on sabbatical.
Sep 29 2021
@rupor-github no problem! :)
Sep 28 2021
@bernhard thank you for explaining, did not mean to offend anybody. Before creating win-gpg-agent I tried to read as much as I could on a history and obviously had to study source a bit. Be it as it may - I decided to have separate wrapper, rather then contributing directly to gpg code base. There is noticable number of use cases on Windows which presently not addressed, some I believe are sitting it the queue already.
@rupor-github thanks for your explanations and the contribution to the GnuPG and crypto Free Software code base!
Since Windows user naively could expect multiple methods of accessing certificates from different programs (or sometimes from the same program but different supported environments, like Git4Win and git in WSL) to work together transparently, win-gpg-agent covers translation of one accidentally supported method (32 bit putty shared memory) to multiple unsupported ones (named pipe, cygwin, etc). It also takes care of managing gpg-agent.exe lifetime tying it to user login session for convenience. It uses command line parameters to only to overwrite staff critical to its functionality and does not prevent user from having configuration file(s). Optionally it provides pinentry which is integrated with Windows native Crypto Vault and UX rather than using wonderful QT or GTK. As specified in documentation when developers of gpg and WIndows will get their act together and figure out what they want and how they want it - most of functionality would not be needed. I would like to point out that simply claiming superiority and not supporting cygwin (Git4Win) or working Assuan ssh socket or putty shared memory in 64 bits Windows build does not help with user experience a single bit.
Lots of detailed documentation but frankly, after a brief read I have not yet figured out what it really does. We won't support Cygwin stuff - this is all obsolete and awe also removed starting gpg-agent as a service for good reasons. Instead of starting gpg-agent with lot of command line args it would be better to put this into a per user or system wide config file.
There is a user report that got things to work with https://github.com/rupor-github/win-gpg-agent
on https://wald.intevation.org/forum/forum.php?thread_id=2359&forum_id=21&group_id=11
Sep 14 2021
Aug 13 2021
Jul 30 2021
Jun 25 2021
That might depend on your pinentry version. With a pre-1.1.1 pinentry and 2.2.28 I get this:
May 12 2021
May 6 2021
Feb 26 2021
The show error is due a missing translation. What happened was that the translation was marked fuzzy and this marker was removed not realizing that the string really changed. The change was "...in the GnuPG system" -> "...in the %s system" which had been done to allow for different gpg names.
Feb 25 2021
Start from scratch on a german system, even when you do a gpg --version it shows it is in german. Then import a PKCS#12 container and the dialog is in english.
A wild guess is that the different envvar systems we have in use are the culprit. It is anyway time to get this straight.
Feb 24 2021
As suggested in the linked question on stackexchange, I think that even if the error comes from the pinentry program, GnuPG could echo a more informative error than gpg: decryption failed: No secret key, such as terminal to little to show the pinetnry program, or something similar.
Feb 23 2021
Thanks for the report. Frankly the curses pinentries are not that widely tested.
Feb 17 2021
Feb 10 2021
The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.
Jan 30 2021
Jan 28 2021
Jan 27 2021
Jan 26 2021
Jan 8 2021
rG47c1c329ed82: agent,ecc: Use of opaque MPI for ECC, fixup 'd'. does the fixup when reading keys.
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.
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.
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.
Nov 30 2020
Nov 27 2020
No more problems reported, so I assume like @aheinecke that it has been resolved in Windows.
Nov 23 2020
Its done for 2.2 thus changing the tag.
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 4 2020
Oct 30 2020
One bug is fixed in rGdd4fb1c8f668: gpg: Fix first zero-byte case for SOS handling..
Fixed in 2.2 branch.
Also, I found another issue of libgcrypt master, which is fixed in rC361a0588489c: ecc: Handle removed zeros at the beginning for Ed25519..
Further, I found different issue, and created T5116: GnuPG master shows an error when importing Ed25519 keys generated.
I think that it may occur with eddsa secret keys generated with 2.2, too. (In the 50% probability)
Oct 29 2020
In short eddsa secret keys generated with current 2.3 can't be imported with 2.2, right? That will lead to a compatibility problem, so we need to fix that in 2.2.
IIUC, it is an issue of GnuPG 2.2.
The condition is where the secret 'd' starts by the first bit = 1 (that is, >= 0x80).
I located the bug in agent/cvt-openpgp.c. The function do_unprotect calls convert_secret_key with skey[1] as usual MPI (not opaque),
and gcry_sexp_build with "(d%m)" will put additional 0x00 at the beginning, which results 33-byte secret in R_KEY. Then, when gcry_pk_testkey is called with R_KEY, when it checks, because 32-byte is expected, it returns GPG_ERR_INV_OBJ. Then, do_unprotect returns GPG_ERR_BAD_PASSPHRASE.
Oct 23 2020
What can be done is to use gpgconf --list-dirs bindir as a fallback for pinentry.
Oct 1 2020
@werner can you confirm if the environment I provided will work with OpenSSH support fully implemented?
Sep 4 2020
So, if there's no support for native OpenSSH yet, I'll wait for it. After it's supported, I should be able to get the scenery I described working, right?
Unfortunately you can't pass extra arguments.
Sep 3 2020
@bvieira You need to set pinentry-mode=loopback for gpg program used in git.
Sep 2 2020
I'm actually trying to do the following:
In the meantime you can use [0]. I have tested with ssh key on yubikey and AuthenticationMethods publickey, win32-ssh (or ssh-portable, which is the new repository name) correctly works with gpg and pinentry is called. Despite it being called wsl, wsl environment is not required.
Aug 25 2020
[These damned typos in commit messages ;-)]
Jul 20 2020
Any news on this?
Jun 9 2020
Jun 2 2020
Change of gpg-agent for ECC-SOS
May 27 2020
Mar 5 2020
I t could print a warning for a non-existant homedir
Sure, I personally know that GnuPG requires a homedir to operate.
As you surely known GnuPG requires its home directory; in particular when using the gpgconf to manage the config options. Thus I can't see what to do other than error out. gpgconf needs to know the location of the config file; if it is containign diretcory is not existant it will fail anyway.