You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the problem you're trying to solve?.
Windows natively supports OpenSSH, including ssh-agent. However, the way ssh-agent works on Windows is different than how it works on macOS / Linux. It uses a Windows specific service, and uses a named pipe instead of the socket file (located at $SSH_AUTH_SOCK) which it uses on POSIX systems.
Describe the feature you'd like
Interoperability between a user's Windows ssh-agent (if configured) to their Finch VM. This should be a togglable feature, since some users may not use Window's ssh-agent, and if its not togglable, it might break any other solution they setup themselves.
Additional context
This issue was first noticed when a new test for build --ssh was added to the common-tests package. See the corresponding comment on the Windows PR: #649.
Since there needs to be a forwarding daemon/long-lived-process running on the Windows side to handle forwarding from the Windows named pipe to a socket, and Finch currently does not have that capability, the most immediate place to add this functionality is to Lima, specifically it's lima-hostagent. I will create a corresponding issue on the Lima repo.
Issue #, if available: runfinch/finch#750,
runfinch/finch#649
*Description of changes:*
- Disable build --ssh test when running on Windows
*Testing done:*
- Ran test suite on Windows machine, and it skipped as expected
```
[SKIPPED] non-functional on Windows, see runfinch/finch#750
In [It] at: C:/Users/Administrator/Code/common-tests/tests/build.go:131 @ 01/05/24 20:18:38.223
------------------------------
[SynchronizedAfterSuite]
C:/Users/Administrator/Code/common-tests/run/run_test.go:36
ef5e5b2ec9fd42f39e6c3a3daac04488b0d7c434446b18eaf4c7c7b6e9cc4ea0
ef5e5b2ec9fd42f39e6c3a3daac04488b0d7c434446b18eaf4c7c7b6e9cc4ea0
0a182cb82c93
Untagged: public.ecr.aws/docker/library/registry:latest@sha256:0a182cb82c93939407967d6d71d6caf11dcef0e5689c6afe2d60518e3b34ab86
Deleted: sha256:9fe9a137fd002363ac64f5af66146702432b638a83ee0c5b620c40a9e433e813
Deleted: sha256:d9bce47b357e434a4b294543f1f58cf3113de1d5356dfcb0c67fad2af92f8633
Deleted: sha256:afcdb1715fb302c8cefa6e90a55c096e13a8d49faee6daaf7745dc0f95f9e90d
Deleted: sha256:9f383ae4f64d95caaff5c106cf502c1a6f65617a4de01f2cad10353c0e825f5c
Deleted: sha256:645ddea727356ff8ceb7f90d5ac0aee83bff1ac1ddae1f964228c3051ea50f50
[SynchronizedAfterSuite] PASSED [3.579 seconds]
------------------------------
Ran 0 of 1 Specs in 25.101 seconds
SUCCESS! -- 0 Passed | 0 Failed | 0 Pending | 1 Skipped
```
- [x] I've reviewed the guidance in CONTRIBUTING.md
#### License Acceptance
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.
Signed-off-by: Justin Alvarez <[email protected]>
What is the problem you're trying to solve?.
Windows natively supports OpenSSH, including ssh-agent. However, the way ssh-agent works on Windows is different than how it works on macOS / Linux. It uses a Windows specific service, and uses a named pipe instead of the socket file (located at
$SSH_AUTH_SOCK
) which it uses on POSIX systems.Describe the feature you'd like
Interoperability between a user's Windows ssh-agent (if configured) to their Finch VM. This should be a togglable feature, since some users may not use Window's ssh-agent, and if its not togglable, it might break any other solution they setup themselves.
Additional context
This issue was first noticed when a new test for
build --ssh
was added to the common-tests package. See the corresponding comment on the Windows PR: #649.Since there needs to be a forwarding daemon/long-lived-process running on the Windows side to handle forwarding from the Windows named pipe to a socket, and Finch currently does not have that capability, the most immediate place to add this functionality is to Lima, specifically it's
lima-hostagent
. I will create a corresponding issue on the Lima repo.Prior art:
The text was updated successfully, but these errors were encountered: