Closed aetonsi closed 1 year ago
This could be counted as a regression of #40 in which initialization with git was introduced.
Instead of trying to parse the git configuration, which could be cumbersome, a check like !$? -or $LASTEXITCODE -eq 128 right after the git clone command should be sufficient. In case of error you can then proceed with cloning via SSH
Downloading zip files as the fallback would be a better way to solve this I guess, considering there might be evironment having SSH cloning disabled.
@xxthunder any thoughts on this?
@chawyehsu @aetonsi Oh yes, this is definitely a regression of #40 , sorry for that. I like your idea falling back to downloading the zips instead. This feature was introduced due to proxy access, so ssh would probably not work in such an environment anyway. I will implement a fallback to zips, so stay tuned.
yeah the zip fallback is surely simpler and more useful than cloning via SSH, i didn't think of that. nice 👍
@chawyehsu Did you have any time looking into my changes?
One question: why should anyone disable https for git? Even if we implement the fallback scoop won't work at all, wouldn't it?
scoop update --all
Updating Scoop...
fatal: transport 'https' not allowed
Update failed.
A simple reason might be to enforce the use of SSH keys, by throwing errors on any accidental use of any other transport. Anyway since it's not some cryptic/unknown git feature, i think it should be taken into consideration, also because sometimes the user might not be administrator and might not have the rights to alter git's configuration or install software, and scoop is a nice way to still run and somewhat manage applications
Bug Report
Current Behavior
Currently the installer (at least the ps1 script for windows) tries to install scoop by cloning the repo only via HTTPS:
If the HTTPS transport protocol is disabled in the git configuration of a user/system, the installer breaks.
Expected Behavior
The installer should try to fallback to SSH.
Additional context/output
This is my installer output:
Running
git config --get-regexp "protocol\..*"
on a system could return something like this:... or
git config --get protocol.https.allow
:... means that HTTPS cannot be used to clone repos. The actual capability of cloning via HTTPS could be also determined by the git config value
protocol.allow
, if set, or the env variableGIT_PROTOCOL_FROM_USER
if the value isuser
. See here: https://git-scm.com/docs/git-config#Documentation/git-config.txt-protocolallowPossible Solution
Instead of trying to parse the git configuration, which could be cumbersome, a check like
!$? -or $LASTEXITCODE -eq 128
right after thegit clone
command should be sufficient. In case of error you can then proceed with cloning via SSH (git@github.com:ScoopInstaller/Scoop.git
).System details
Windows version: 11 (
Microsoft Windows [Version 10.0.22621.1702]
)OS architecture: x64
PowerShell version: 7.3.4
Additional software:
git version 2.40.1.windows.1
,OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
Scoop Configuration