martinvonz / jj

A Git-compatible VCS that is both simple and powerful
https://martinvonz.github.io/jj/
Apache License 2.0
7.3k stars 242 forks source link

`jj git push` is not working for me on Windows #3322

Open jyn514 opened 3 months ago

jyn514 commented 3 months ago

Description

whenever i run jj git push, i get one of the two errors:

Steps to Reproduce the Problem

i have no idea. i don't believe this is related to my .ssh/config, since ssh -F /dev/null git@github.com succeeds. i have the following env variables set on WSL:

; set | grep '^SSH'
SSH_AGENT_PID=48
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXzGR8a4/agent.47

those aren't set on windows, but ssh-agent is somehow working anyway; at least, ssh-add succeeds.

Expected Behavior

jj is able to push to the remote.

Specifications

gulbanana commented 3 months ago

the second one might be https://github.com/libgit2/libgit2/issues/6612 iirc i’ve worked around this in the past by ensuring my known_hosts does not contain an ed25519 key for github

MordechaiHadad commented 3 months ago

I am getting the same issue on windows (not WSL):

PS D:\repos\LeadLens> jj git push -c "@-"
Creating branch push-nroqnvwmpzqn for revision @-
Branch changes to push to origin:
  Add branch push-nroqnvwmpzqn to e06c042721af
Error: Failed to authenticate SSH session: ; class=Ssh (23)
Hint: Jujutsu uses libssh2, which doesn't respect ~/.ssh/config. Does `ssh -F /dev/null` to the host work?
HybridEidolon commented 2 months ago

Similar issue here; I am cloning a repository from a private GitLab service using Windows and the remote ssh key is ed25519, and getting "Error: Fetch failed: failed to set hostkey preference: The requested method(s) are not currently supported; class=Ssh (23)". If I comment out the known_hosts line, I instead get "Fetch failed: failed to start SSH session: Unable to exchange encryption keys; class=Ssh (23)"

HybridEidolon commented 2 months ago

libssh2 error code 23 is LIBSSH2_ERROR_CHANNEL_UNKNOWN which is either "Packet received for unknown channel" or "Channel not found". That's really strange. This seems to affect jj all the way back to 0.7 (which was what cargo installed for some reason). Is libgit2 doing something it shouldn't?

HybridEidolon commented 2 months ago

I've tracked down the issue. The Windows Cryptography Next Generation API backend for libssh2 do not have support for ED25519 and libssh2-sys is defaulting to use it instead of OpenSSL when targeting win32 (either msvc or mingw). libssh2-sys must be compiled with the openssl-on-win32 feature (and vendored-openssl) in order to use the OpenSSL backend.

All distributions of git on windows use a combination of cygwin and git itself which are all compiled to use openssl, which is why it's not a common issue for windows git users. But when using libgit2 directly, this is something to be conscientious of I guess.