Comments (12)
I didn't try it, but maybe it only works in a powershell? Even though it aims to be compatible to Asciinema, I have a feeling that it will not play similarly in every terminal. Personally, I didn't try to play it back at all, too many hoops for me.
I tried both. In Bash using asciinema and in PowerShell using PowerSession. Both through Windows Terminal, though the former in WSL2. Both had identical results.
from gitoxide.
Attempting to read the raw PowerSession log makes it look like the extra backslashes are really present in the configured value, but I am far from sure. Furthermore, repeated directory separators should not keep a path from working, so even if that is the case, it is not itself sufficient to dismiss this issue.
However, with only the information here so far, I think it is unclear that there is really a bug. Furthermore, if there is a bug, and it is later fixed, I think it would be hard even to know it was the same bug as described here. Likewise, if a bug is fixed that seems to match this, that might still be a different bug.
If this configuration is working with git
, or of there is some way to provide a readable log that shows the problem and shows that it is not due to an incorrect configuration, then that would be different.
Instead of recording, I recommend copying the text from the terminal, and pasting it into the issue description (or into a new comment).
-
If this is Windows PowerShell then the way you would copy the text depends what console application is being used. But in the old traditional console host program, copying can be achieved by opening the PowerShell window's system menu, by clicking it on the upper left corner of the window or by pressing Alt+Spacebar, and doing Edit > Select all, then again opening the system menu and doing Edit > Copy. (There are other ways to do it, but this way has the advantage that it does not produce strange or misleading results even if it is accidentally attempted in an application other than the old console host.)
-
If you are using Windows PowerShell in Windows Terminal rather than the old traditional console host, then copying is easier: you can select text in the terminal, and then press Ctrl+Shift+C. That is, add a Shift to the usual key combination. (This is because Ctrl+C instead sends a signal to interrupt the program running in the terminal, so using that, without Shift, is not always effective at copying.)
-
Once copied, the text can be pasted into most applications, including web browsers, in the usual way (Ctrl+V). When editing an issue description or comment, it can be presented with correct and readable formatting by putting it in a code block with the Markdown code fence feature, achieved with
```
lines at the beginning and end:This text is before the code block. ``` This text is inside the code block. Text from a terminal will have its formatting preserved. For example, this is indented because its leading spaces are rendered. And these words have big gaps between them. ``` This text is after the code block.
That will look like:
This text is before the code block.
This text is inside the code block. Text from a terminal will have its formatting preserved. For example, this is indented because its leading spaces are rendered. And these words have big gaps between them.
This text is after the code block.
Images, videos, and similar representations of terminal actions or contents tend to be much more difficult to use for debugging purposes than the actual text from the terminal. Copying and pasting the text is, in my opinion, by far the best way to share it, in nearly all situations.
However, if for some reason none of that is possible or you otherwise strongly prefer to present the playback of a recording, then you could upload the recording linked in #1432 (comment) (or a new one) to asciinema.org
, much as you had uploaded the first one.
You may already have done this, but if so, that is not readily discoverable, because your account there currently does not have any public recordings (that is, other people need the link to see it).
from gitoxide.
好的,我会尝试一下
from gitoxide.
Could you also show what Git does with git clone …
? It might help to run it with GIT_TRACE=1
.
Additionally, it would be good to see SSH related configuration of the output of gix config | grep -i ssh
, if any is available (but probably there isn't).
Oh, and learning where git.exe
and ssh.exe
are located would also help.
Otherwise I could imagine that it finds ssh.exe
somehow and all by itself, but in the wrong place:
gitoxide/gix-command/src/lib.rs
Line 221 in 3e5c974
The reason it has to do its own PATH lookup is to prevent Windows to launch executables that are in the current working directory, which is a blunder
My feeling is that it should be able to find ssh.exe
from git --exec-path
, but doesn't because it only searches PATH
.
Also CC @EliahKagan
from gitoxide.
General Windows, Rust, and gitoxide path search subtleties
The reason it has to do its own PATH lookup is to prevent Windows to launch executables that are in the current working directory, which is a blunder
It's true that the underlying CreateProcessW
function will search in the current directory before searching in PATH
when running a program specified with no \
. Fortunately, since rust-lang/rust#87704, std::process::Command
has performed its own path search to resolve full paths, so that what actually gets passed to CreateProcessW
is safe.
(That fix came in with Rust 1.58.0, per the milestone linked from the PR and the tags listed as having the merge commit. The minimum supported Rust version for gitoxide is currently 1.67.0.)
For this reason, I am not sure if any of the manual PATH
searching done in gitoxide is actually needed for security. However, I am reluctant to rush to change it, because:
-
The rules
gix_command
uses, when it does its ownPATH
search, differ both from thestd::process::Command
rules and theCreateProcessW
rules. In addition to often searching in the current directory,CreateProcessW
searches various other directories besides those inPATH
that, unlike the current directory, are typically safe to search, though sometimes surprising.std::process::Command
preserves most of that behavior.gix_command
searches only the directories listed inPATH
. Thestd::process::Command
rules are probably the best way to go for Rust code where there is not a specific reason to do otherwise, but I would still want to fully understand the ramifications of changing thegix_command
behavior in this area. -
There may be other or related considerations specific to parsing
#!
lines in scripts that would need to be preserved across any such changes. That's not relevant togix_transport
and SSH, but it's part of what thegix_command
crate has functionality for. -
Even without letting
std::process::Command
take care of the lookup,gix_command
still usesstd::process::Command
to run the command, rather than usingCreateProcessW
directly. Thus, I believegix_command
already benefits from other security enhancements instd::process::Command
, such as the fix for CVE-2024-24576 (GHSA-q455-m56c-85mh).
Depending on what turns out to be going on in this issue, all the above might be peripheral. Either way, I should probably post something separate about this. If it's just about how things are good and don't need to be changed, I can make a discussion post; if it's about how maybe things should be changed to simplify some code in gitoxide and bring gix_command
path search rules in line with std::process::Command
, I can make an issue. Not having figured out which is the main reason I haven't posted anything for this yet.
We don't find ssh
the same way as Git for Windows, and we probably shouldn't
My feeling is that it should be able to find
ssh.exe
fromgit --exec-path
, but doesn't because it only searchesPATH
.
I don't think the SSH client path can be gotten directly from git --exec-path
, because that only reveals the location of the git-core
directory that the git
executable being run uses. A full installation of Git for Windows will have various executables that can usually be found relative to this, including its own ssh
executable that ships with it. This is not in the PATH
used outside of the Git Bash environment, but it is what Git for Windows uses by default, even if another ssh
executable is present in the PATH
in the environment where git
is invoked. So perhaps this is what you mean.
But I would not recommend that gitoxide default to using the ssh
that ships with Git for Windows, when that is not present in PATH
. gitoxide does not currently do this--though of course it will find that ssh
if run in an environment where it is first in PATH
, such as in Git Bash. I am somewhat inclined to say gitoxide should (continue to) give no special treatment or recognition to Git for Windows's bundled ssh
at all. But I especially don't recommend changing gitoxide to prefer it over a more readily available ssh
. My rationale is:
-
Although gitoxide will use Git to obtain information about configuration, when present, it does not rely on Git being present. Since gitoxide does not run Git to actually perform transport commands, it would be extremely unintuitive and strange for gitoxide to use the
ssh
provided as part of Git for Windows, if that is different from thessh
that is run when the user runsssh
. -
I am not aware of any strong reasons other than backward compatibility for Git itself to prefer its own bundled
ssh
to anotherssh
in thePATH
used to run it. Backward compatibility is a strong reason, for Git, and so I am unsure if Git should change this behavior. But thessh
command it bundles is far less convenient than thessh
command that is usually present in all currently supported versions of Windows. The latter integrates with a version ofssh-agent
that is installed as a Windows service, can be controlled inservices.msc
(or with thenet
command), and integrates with Windows credential management features to simplify decrypting stored private keys. -
The
ssh
that ships with Git for Windows seems, fairly or not, to be disfavored by users, even in the absence of an OpenSSH build that integrates with Windows. Before such a build was widely available, I believe the more common practice than using the bundledssh
, among Git for Windows users who used SSH heavily and needed an SSH agent, was to use PuTTY, with its agent, Pageant.
Of course, when the GIT_SSH
environment variable is set, gitoxide should respect that, as Git does.
Troubleshooting this issue
The ssh
that comes with Windows is ssh.exe
in the OpenSSH
subdirectory of the System32
directory. This path is most often, though not always, C:\Windows\System32\OpenSSH\ssh.exe
. The error message shown in this issue seems to refer to it, but something odd is going on with the backslashes:
Error: failed to invoke program "C:\\\\Windows\\\\System32\\\\OpenSSH\\\\ssh.exe"
At most I would expect each backslash to be shown escaped by one extra backslash, such as if this is a string whose debug representation is being shown. Then each backslash in the path would be shown as \\
. But this shows \\\\
for each one. So maybe that has something to do with what is going wrong.
Another curious thing is that (Get-Command ssh).Path
shows:
C:\Program Files\OpenSSH\ssh.exe
That's not inherently surprising, since another version of OpenSSH may have been installed there, or perhaps the usual ssh.exe
in System32\OpenSSH
is absent and so this is the only installation of it. The question is why gix clone
is not using this SSH.
I recommend checking the GIT_SSH
environment variable, as well as the GIT_SSH_COMMAND
environment variable. For example, if GIT_SSH
is set to C:\Windows\System32\OpenSSH\ssh.exe
, then that would explain why that ssh.exe
and not the one under Program Files
is being used, though I'm still not sure what the deal is with the quadruple backslashes. If GIT_SSH
is set to something that actually has doubled literal backslashes, then that's the problem.
If GIT_SSH
is not the problem but GIT_SSH_COMMAND
is not set (and the core.sshCommand
configuration variable is not set), then it may be possible to work around this problem by setting GIT_SSH
, though of course there would still be an underlying gitoxide bug, or configuration problem.
from gitoxide.
Thanks a lot for researching this, @EliahKagan. Your help is much appreciated (as always :)).
Depending on what turns out to be going on in this issue, all the above might be peripheral. Either way, I should probably post something separate about this. If it's just about how things are good and don't need to be changed, I can make a discussion post; if it's about how maybe things should be changed to simplify some code in gitoxide and bring
gix_command
path search rules in line withstd::process::Command
, I can make an issue. Not having figured out which is the main reason I haven't posted anything for this yet.
Thanks for researching this! If memory serves, gix-command
implements how Git executes hooks and sub-commands, with special handling that is implemented on Windows. Thus I think this handling should generally stay, but of course, should also be unsurprising.
This is not in the
PATH
used outside of the Git Bash environment, but it is what Git for Windows uses by default, even if anotherssh
executable is present in thePATH
in the environment wheregit
is invoked. So perhaps this is what you mean.
Yes, this is what I meant. gitoxide
already uses the git installation directory to obtain additional configuration which is required for invoking credential helpers, and I think it should act like Git in other ways as well, for instance, when finding the correct ssh.exe
.
[..] it would be extremely unintuitive and strange for gitoxide to use the
ssh
provided as part of Git for Windows, if that is different from thessh
that is run when the user runsssh
.
I agree, but also think that gitoxide
has to strive for compatibility. Thus, as fallback, it should be able to find the bundled ssh
command.
gix-command
certainly is the right place to add such handling if it is opt-in.
Of course, when the
GIT_SSH
environment variable is set, gitoxide should respect that, as Git does.
And it does. You might find interesting that it reads all environment variables that map to git configuration on repository initialization, creating environment overrides in the configuration accordingly.
gitoxide/gix/src/config/cache/init.rs
Line 593 in d2ae9d5
That way environment variables that affect the runtime then become explicit:
GIT_SSH=ssh-without-shell GIT_SSH_COMMAND=ssh-override gix config
# From 'memory' (EnvOverride)
[..]
# From 'memory' (EnvOverride)
[gitoxide "ssh"]
commandWithoutShellFallback = ssh-without-shell # from GIT_SSH
[core]
sshCommand = ssh-override # from GIT_SSH_COMMAND
@Mr-Ao-Dragon Could you check if the environment variables mentioned above are set to a value and if so, post it here? Finally, could you see if you can invoke C:\\Windows\\System32\\OpenSSH\\ssh.exe
and C:\Windows\System32\OpenSSH\ssh.exe
respectively? Thank you.
from gitoxide.
ok, i will try it
from gitoxide.
I've set it up based on this blog
power session rec file
from gitoxide.
Apologies, but I don't think any of my questions was answered.
from gitoxide.
Apologies, but I don't think any of my questions was answered.
I actually don't know what's going on, I tried the diagnostic commands you guys provided about gix but that didn't do anything, it's strange, gix does seem to detect the path but it seems to be ambiguously on the path, I found it detects more paths with more \\
from gitoxide.
I've set it up based on this blog power session rec file
Attempting to playback the linked asciinema/PowerSession recording looks broken
from gitoxide.
I didn't try it, but maybe it only works in a powershell? Even though it aims to be compatible to Asciinema, I have a feeling that it will not play similarly in every terminal. Personally, I didn't try to play it back at all, too many hoops for me.
In a way, this issue seems stalled in terms of acquisition of information, but I hope that maybe similar issues arise with others who might chime in. In any case, I am sure eventually we will get to the bottom of this.
from gitoxide.
Related Issues (20)
- OSS-Fuzz issue 70323 HOT 1
- Something went wrong... & Merge conflict after working on another device HOT 1
- `gix clean -xde` deletes whole repo if `.gitignore` lists `*` or `/` HOT 6
- The kstring integration in gix-attributes is unsound HOT 5
- Fallback to git commands? HOT 3
- `gix clean` with `-r` or `-xd` deletes the repo's own nested worktrees HOT 5
- audit uses of `as_ref()` and remove those that are ambiguous HOT 6
- gitoxide fails to compile with bstr 1.9.2 HOT 1
- `gix clean -xde` deletes the repo's own hidden nested worktrees, but they are not really hidden HOT 5
- The 32-bit Windows releases are 64-bit HOT 6
- Unclear intent regarding optimizations for some profiles HOT 5
- Prebuilt binaries obtained on ARM64 macOS are x86-64 HOT 5
- OSS-Fuzz issue 70841 HOT 1
- OSS-Fuzz issue 70863 HOT 1
- Release workflow relies on deprecated `set-output` feature
- OSS-Fuzz issue 70876 HOT 1
- `from_path_no_follow` test runs `touch` with nonportable date format HOT 3
- Panic when parsing `HEAD:README` in a repo with invalid HEAD. HOT 2
- gitx-credentials fails to build HOT 4
- copy detection differs from git weirdly HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gitoxide.