I see the reason.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 26 2024
Dec 21 2023
Dec 19 2023
FWIW: These days a thread on Linux is not that costly but nevertheless takes up resources. On other Unices (and WindowsCE) threads have quite some overhead and that was the reason I implemented it the way it was.
Nov 20 2023
works, VS-Desktop-3.1.90.287-Beta
Nov 15 2023
So the actual killing is now done with c5617e9f2426549cba54cb52f9faf9325f8e2929 we are using custom actions instead of CloseApplication to have more fine grained control when the steps are run. CloseApplication would only run in the main install sequence so basically only the Deferred part, but during an interactive upgrade like what one of our Entry users would do it would not avoid the first failure to kill a running gpg-agent this already would break the RestartManager support.
FWIW, the Fileversion is actually the Git revision in decimal
b) Is explained by the following documentation from: https://wixtoolset.org/docs/v3/howtos/updates/major_upgrade/
a) So with my current test upgrading from one beta to another it actually looks in the manifest and if you look there the beta230 of gnupg:
So with verbose logging /l*v inst.log (note the v) I finally saw the issue. My killing code works just fine.
Nov 14 2023
Nov 12 2023
Ok closeapplication will not work because:
Nov 10 2023
Note to self.
So some research led me to believe that using taskkill from MSI is not uncommon. But most stackoverflow solutions did not work for me. I have one solution that works, though but that opens a terminal window for each process we try to kill. I don't want to use wscript to avoid that, since an installer that executes visual basic is IMO even more evil then an installer that executes taskkill. Both are not really the MSI way, but while we could fix our processes without a WindowMessage loop to die nicely this will not work for an upgrade to vsd32.
Nov 3 2023
So I tested upgrading from 3.1.26.0 to the current beta and it also did not work.
Oct 25 2023
Oct 16 2023
Oct 10 2023
Aug 30 2023
Push the code by rG95186ae92f92: agent: Use a thread to monitor socket takeover.
May 25 2023
FWIW: I have not done any tests but the comment below is about the case I suspected to be the cuase for your problem:
May 8 2023
If it were the case, I think that graceful shutdown of the system would need to terminate the client of scdaemon at first.
The root cause might be that the "DEVINFO --watch" command causes ...
May 7 2023
I also experienced hang on shutdown with GPG 2.4.1 and bisecting reveals that the first bad commit is rG2ccbcfec121f.
Apr 14 2023
Apr 13 2023
isn't T3456 the same issue?
Apr 5 2023
Mar 15 2023
FYI: Quite some more days than a few passed by. I still did not found the time for this, sorry.
Mar 14 2023
Mar 13 2023
I never made a threat model. But definitely *any* cracker, should be out of my system, either from governmental agencies or from a kiddo in Russia.
I know that I have someone that is remote accessing my machine, since I got some tells. And that this cracker have used my Emacs text editor.
Smartcard PINs are different from passphrase for on-disk keys. Once a PIN is entered the smartcard is unlocked as long as it is powered up. In theory we could power down and power up the card to lock it. The question here is what is your threat model? If you have malware on your system it could simply brick your token or, more common, peek at your PIN.
Mar 11 2023
Feb 16 2023
Thanks. please give a few days.
created ~/.gnupg/gpg-agent.conf containing:
debug ipc,cache debug-pinentry log-file socket://
Okay, I see. The commands above are a real reproducer and not standalone examples. Then yes, you should get a pinentry only for the first gpg -d (as long as the keys are still in the cache). I am lacking macOS/homebrew stuff to replicate this. What you can do is to put
Feb 15 2023
I may be reading your comment wrong, but the problem here is not multiple pinentry prompts, or multiple gpg-agents present.
Although gpg-agent launching is protected by a file system lock, there is indeed a small race related to the pinentry. The invocation of the pinentries is serialized but if a second pinentry is requested while the first pinentry has not yet returned and put the passphrase into the cache, the second pinentry will be called anyway. Fixing this not easy and should rarely be a problem. The mitigation is to do a dummy decryption to seed the cache or use a custom pinentry.
Jan 19 2023
Dec 22 2022
Thanks all. It is a bug in Win32 OpenSSH. https://github.com/PowerShell/Win32-OpenSSH/issues/1953 it is already fixed. I think the issue will be resolved after the update is shipped. I could use ssh -T git@github.com as a workaround.
Well, not our bug... it's a kind of support question and answer:
This might help: https://stackoverflow.com/questions/3844393/what-to-do-about-pty-allocation-request-failed-on-channel-0
Dec 21 2022
This does not look like a problem in GnuPG/gpg4win because gnupg implements the ssh-agent protocol and not the ssh server or client functionality. ssh tells sshd whether it shall allocate a PTY (Pseudo TTY). I don't use ssh with github but it is likely that you may only run commands (which don't require a PTY). Usually you would invoke a "git" command cia ssh.
Authentication succeed if I pressed enter after:PTY allocation request failed on channel 0
I try WinGPG 4.1.0, and I receive an error:
ssh git@github.com
PTY allocation request failed on channel 0
Dec 5 2022
Nov 25 2022
Implications are... you won't be possible to use new protocols introduced by newer OpenSSH:
Nov 24 2022
Thanks. Adding 'PubkeyAuthentication unbound' to my ~/.ssh/config seems to workaround it for me on openssh-9.1p1-3 (arch). I don't quite follow what the implications of that setting are though.
In my cases (tested with 9.1), here are the length of data to be signed by ssh-agent (emulation by gpg-agent).
- 164 bytes: Both features disabled by: ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com -o PubkeyAuthentication=unbound
- 192 bytes: Unbound only by: ssh -o PubkeyAuthentication=unbound
- 298 bytes: No Post Quantum only by: ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com
- 330 bytes: Both features enabled (no options)
Nov 22 2022
I tested with openssh 9.1. When I add -o PubkeyAuthentication=unbound, I can make the length of data smaller.
Nov 9 2022
In T5931#165009, @alexk wrote:A workaround you can add the following line to ~/.ssh/config or /etc/ssh/ssh_config:
KexAlgorithms -sntrup761x25519-sha512@openssh.comFor me ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com ... does work as well.
A workaround you can add the following line to ~/.ssh/config or /etc/ssh/ssh_config:
Oct 28 2022
Will go into 2.3.9 and gpg4win 4.0.5
Oct 26 2022
Oct 14 2022
Pushed to master.
Sep 22 2022
Sep 20 2022
Testing gpg-auth : There are two different use cases
- test with xsecurelock for screen lock
- test with pam-autoproto for login / gdm / etc.
Here are pam_authproto.c with Makefile, so that you can compile it with libpam:
Sep 19 2022
I hacked configure.ac of gnupg to force it build with libgpg-error 1.45, and OpenSSH works with the created pipe. Maybe the libgpg-error fix is only necessary in some certain circumstances?
Sep 14 2022
works now
Sep 9 2022
Here is a PAM module, which interact a spawned process using authproto protocol of xsecurelock.
Sep 7 2022
It's not yet pushed, because it requires new release of libgpg-error (for T6112: libgpg-error,w32: bidirectional Pipe support for estream).
Sep 6 2022
I was looking for this when writing the update NEWS for the latest release and noticed that this has not been pushed yet. I really think that it would be nice to have that. Especially for Smartcard use cases.
Sep 2 2022
Thanks for testing. I guess I will do a new release.
Sep 1 2022
Applies cleanly and fixes the crash. 👍
For master (2.3) the fix is not needed due to another way the code works, but having a more robust function is always good.
You may try the above commit - if should apply cleanly to 2.2.37.
You are right. This due to your old binary private key (stubs). Otherwise you would at least have one item ("Key:"). I need to see what do do about the release. Maybe a tool to update the key files would we a good workaround.
Aug 26 2022
Fully done in my opinion.
Aug 24 2022
Isn't this (mostly?) done? See T5517: Improvements for symmetric encryption.
Aug 23 2022
Aug 19 2022
Probably, PIPE_REJECT_REMOTE_CLIENTS mode and lpSecurityAttributes=NULL is OK.
Aug 11 2022
While playing with your scripts I figured that it would be useful to enhance the KEYINFO command. With
rG989eae648c8f3d2196517e8fc9cce247b21f9629 we could now
Aug 4 2022
Please reopen my issue. This is a serious issue that we encounter and do not have any explication.
Hi!
No, it's not waiting for the password. This was a 2 times error happening on our server.
We already provided the password but it was hung. We entered different things but it won't make anything.
I can tell you it doesn't wait for anything because we tested the same command on 2 different machines. On one machine it was hung, on another it worked.
gpg was waiting for the passphrase for the signing key to be provided via stdin.
Aug 1 2022
Jul 29 2022
Jul 28 2022
Probably, PIPE_REJECT_REMOTE_CLIENTS mode and lpSecurityAttributes=NULL is OK.
Here is the parser output:
$ python3 sd.py --type=pipe "D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU)" D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU) Discretionary ACL: P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU) Flags: P: SE_DACL_PROTECTED (Blocks inheritance of parent's ACEs)
I think that the last argument of CreateNamedPipeA can limit the access to the named pipe.
Here is a patch to implement the functionality with --enable-win32-openssh-support.