stephengillie
commented
1 year ago One thing though, this is the exact message one gets when trying to run a second tkey-ssh-agent that tries to create the same Named Pipe as the first.
This is likely what happened. Validation installs the package, runs all changed executables and script files, then performs a Defender scan. Frequently a package will be run multiple times, as it's launched by EXE, 1 or more LNK each on personal and public desktops and start menus, and possibly another means (such as a script file in the package). It's rare for a package to behave one way on first run and then differently on subsequent runs - here it's due to having already created the listener. And the old "meme" of a functional blocker being reported as a permissions error.
quite
A moderator of the winget community pkgs helpfully gave this comment about running tkey-ssh-agent. They wrote
In a VM without the USB key, it gives this message:and posted a screenshot of a notification from tkey-ssh-agent that readstkey-ssh-agent | Could not create listener: ListenPipe: open \\.\pipe\tkey-ssh-agent: Access is denied.(https://github.com/microsoft/winget-pkgs/pull/103026#issuecomment-1516774885)The TKey USB not being plugged in really should not matter, we don't even try to connect to it until tkey-ssh-agent is asked for some action. We did not run into this ourselves during our testing on Windows 11 running in QEMU, and on Windows 10 on hardware.
Could there be some setup where user running the agent does not have permission to create a named pipe? And does that have any relation to our SecurityDescriptor setup in
listen_windows.go?One thing though, this is the exact message one gets when trying to run a second tkey-ssh-agent that tries to create the same Named Pipe as the first. Could you have happaned to do that @stephengillie