+ # Does the release's ssh.exe have the libcrypto it needs? Decided before the\r
+ # download so the answer can also gate what comes out of the zip. This is a\r
+ # cheap pre-filter only - the authoritative check is running the thing, which\r
+ # happens after the unpack below.\r
+ $SysCrypto = Join-Path $env:WINDIR 'System32\libcrypto.dll'\r
+ $WantSsh = Test-Path $SysCrypto\r
+ if (-not $WantSsh) {\r
+ Write-Warning "$SysCrypto is missing - the OpenSSH Client capability is not installed - and the release's ssh.exe needs it. Installing rsync.exe only; rsync will use the ssh on the PATH."\r
+ } else {\r
+ $v = (Get-Item $SysCrypto).VersionInfo.FileVersion\r
+ if ($v -and ([version]($v -replace '[^0-9.]', '')) -lt [version]'3.8.2') {\r
+ Write-Warning "$SysCrypto is LibreSSL $v; the release's ssh.exe is built against 3.8.2 (Windows OpenSSH Client 9.5). Update Windows, or expect ssh.exe not to start."\r
+ }\r
+ # No architecture special-case here any more: the asset chosen above\r
+ # matches the host, so the release's ssh.exe and System32's libcrypto.dll\r
+ # are the same architecture on every box. The run-it check below still\r
+ # happens on all of them - it is cheap, and it is what caught the ARM64\r
+ # mismatch back when this took the x64 zip.\r
+ }\r
+\r
+ # Download and unpack beside the targets, not over them, so an interrupted\r
+ # transfer can't leave a truncated rsync.exe sitting on the PATH. The scratch\r
+ # name still has to END in .zip: Windows PowerShell 5.1's Expand-Archive\r
+ # refuses any other extension outright ("*.download is not a supported\r
+ # archive file format"), where PowerShell 7 just reads the file.\r
+ [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12\r
+ $tmpZip = Join-Path $RsyncDir "download-$RsyncAsset"\r
+\r
+ # The .sha256 published beside the zip is fetched FIRST, for two jobs. It\r
+ # verifies the download below. Same origin, so that is an integrity check on\r
+ # the transfer rather than a defence against a hostile release - but a\r
+ # truncated or proxy-mangled download is the failure that actually happens,\r
+ # and it fails here instead of mid-transfer later.\r
+ #\r
+ # And it says whether there is anything new to fetch at all. The hash of the\r
+ # zip the installed files came from is recorded beside them in\r
+ # rsync-windows.sha256, written only once they have all landed (as BinSkim's\r
+ # nupkg-version.txt is). When the release's hash still matches and the files\r
+ # are all there, the download and unpack are skipped - a re-run costs one\r
+ # small request instead of the zip. An ssh.exe that was wanted but is gone\r
+ # (removed below for not starting) does NOT count as there, so each run\r
+ # tries it again: whatever stopped it starting may have been fixed since.\r
+ #\r
+ # -OutFile, not .Content: GitHub serves the .sha256 as\r
+ # application/octet-stream, and Invoke-WebRequest hands back a byte[] rather\r
+ # than a string for any non-text content type, so .Content would compare the\r
+ # first BYTE against the hash and fail on every correct download.\r
+ $tmpSha = "$tmpZip.sha256"\r
+ Invoke-WebRequest -Uri "$RsyncUrl.sha256" -OutFile $tmpSha -UseBasicParsing\r
+ $want = (((Get-Content $tmpSha -Raw) -split '\s+')[0]).Trim().ToLower()\r
+ Remove-Item $tmpSha -Force -ErrorAction SilentlyContinue\r
+\r
+ $RsyncMarker = Join-Path $RsyncDir 'rsync-windows.sha256'\r
+ $InstalledSha = if (Test-Path $RsyncMarker) { (Get-Content $RsyncMarker -Raw).Trim().ToLower() } else { '' }\r
+ $RsyncCurrent = $want -and ($InstalledSha -eq $want) -and (Test-Path $RsyncExe) -and\r
+ (-not $WantSsh -or (Test-Path (Join-Path $RsyncDir 'ssh.exe')))\r
+ if ($RsyncCurrent) {\r
+ Write-Host " $RsyncAsset unchanged since it was installed (SHA-256 $want); not downloading it again."\r
+ } else {\r
+ Invoke-WebRequest -Uri $RsyncUrl -OutFile $tmpZip -UseBasicParsing\r
+ Write-Host " Downloaded $RsyncAsset ($([math]::Round((Get-Item $tmpZip).Length / 1MB, 2)) MB)"\r
+ $got = (Get-FileHash $tmpZip -Algorithm SHA256).Hash.ToLower()\r
+ if ($want -and $want -ne $got) {\r
+ Remove-Item $tmpZip -Force\r
+ throw "SHA-256 mismatch for ${RsyncAsset}: expected $want, got $got"\r
+ }\r
+ Write-Host " SHA-256 verified: $got"\r
+\r
+ # Unpack to a scratch directory and move out the files we asked for, rather\r
+ # than expanding straight over the install directory: the zip is the unit\r
+ # that was checksummed, and this way a future release adding something to it\r
+ # cannot quietly drop that something onto the machine PATH.\r
+ $unpack = Join-Path $RsyncDir '.unpack'\r
+ if (Test-Path $unpack) { Remove-Item -Recurse -Force $unpack }\r
+ Expand-Archive -Path $tmpZip -DestinationPath $unpack -Force\r
+ Remove-Item $tmpZip -Force\r
+ foreach ($f in 'rsync.exe', 'ssh.exe', 'COPYING.txt', 'NOTICE-ssh.txt') {\r
+ $src = Join-Path $unpack $f\r
+ if (-not (Test-Path $src)) { continue }\r
+ if ($f -eq 'ssh.exe' -and -not $WantSsh) { continue }\r
+ Move-Item -Path $src -Destination (Join-Path $RsyncDir $f) -Force\r
+ }\r
+ Remove-Item -Recurse -Force $unpack\r
+ # Written last: the marker must only claim a release that fully landed.\r
+ if ($want) { Set-Content -Path $RsyncMarker -Value $want -Encoding ascii }\r
+ }\r
+\r
+ # Prove the unpacked ssh.exe actually starts, and DELETE it if it does not.\r
+ #\r
+ # This matters more than it looks. rsync.exe prefers an ssh.exe sitting in its\r
+ # own directory, so a present-but-unstartable one does not degrade to the\r
+ # in-box client - it breaks rsync outright, and the error you get is a remote\r
+ # shell that died rather than anything naming ssh.exe. The way to land there\r
+ # is a missing or too-old System32 libcrypto.dll. Removing it is the repair:\r
+ # rsync then falls back to the ssh on the PATH, which is the in-box client.\r
+ #\r
+ # This also used to fire on every ARM64 run, when the x64 asset was the only\r
+ # 64-bit one published and its ssh.exe could not load the ARM64 libcrypto\r
+ # (exit 0xC0000135, STATUS_DLL_NOT_FOUND). The arm64 asset fixed that at the\r
+ # source; the check stays because it is how that was found in the first place.\r
+ #\r
+ # EAP back to Continue for the call: ssh -V writes its version to STDERR, and\r
+ # under $ErrorActionPreference = 'Stop' a native command's stderr becomes a\r
+ # terminating error, so a WORKING client would look like a broken one.\r
+ # $global:LASTEXITCODE is cleared first because an exe that cannot start at\r
+ # all throws without setting one, and the stale 0 from the previous native\r
+ # command would otherwise read as success.\r
+ #\r
+ # DRAIN THE OUTPUT BEFORE READING $LASTEXITCODE. `... | Select-Object -First 1`\r
+ # was the original spelling here, and it is a trap: Select-Object stops the\r
+ # pipeline the instant it has its one object, and that is when ssh.exe has\r
+ # WRITTEN its banner - not when it has exited. PowerShell then tears the\r
+ # pipeline down, kills the still-running process, and reports -1. Measured on a\r
+ # healthy binary on an x64 box: 24 of 25 runs reported exit -1 through\r
+ # Select-Object, and 25 of 25 reported 0 when the output was collected first.\r
+ #\r
+ # So this check was deleting a perfectly good ssh.exe on almost every run, on\r
+ # every architecture, and the resulting fallback to the in-box client - the\r
+ # ~17MB/s one this whole step exists to avoid - looked like a property of the\r
+ # release rather than a bug in the test. Collect, THEN take the first line.\r
+ $SshExe = Join-Path $RsyncDir 'ssh.exe'\r
+ if ($WantSsh -and (Test-Path $SshExe)) {\r
+ $prevEap = $ErrorActionPreference\r
+ $ErrorActionPreference = 'Continue'\r
+ $global:LASTEXITCODE = $null\r
+ $sshVer = $null\r
+ try { $sshOut = (& $SshExe -V 2>&1); $sshVer = $sshOut | Select-Object -First 1 } catch { }\r
+ finally { $ErrorActionPreference = $prevEap }\r
+ if ($LASTEXITCODE -eq 0) {\r
+ Write-Host " ssh.exe runs: $sshVer"\r
+ } else {\r
+ $why = if ($null -eq $LASTEXITCODE) { 'it would not start' } else { "exit $LASTEXITCODE" }\r
+ Write-Warning "The release's ssh.exe does not run here ($why)$(if ($sshVer) { ": $sshVer" }). Removing it so rsync.exe falls back to the ssh on the PATH instead of failing on it."\r
+ Remove-Item $SshExe -Force -ErrorAction SilentlyContinue\r
+ $WantSsh = $false\r
+ }\r
+ }\r
+ Write-Host " $(if ($RsyncCurrent) { 'Kept' } else { 'Installed' }) $RsyncExe$(if ($WantSsh) { ' and the ssh.exe it runs' })"\r
+\r
+ # Machine PATH (HKLM environment). Idempotent: only appends if absent.\r
+ $m = [Environment]::GetEnvironmentVariable('Path', 'Machine')\r
+ if (-not $m) { $m = '' }\r
+ if (($m -split ';') -notcontains $RsyncDir) {\r
+ $new = if ($m.Trim()) { $m.TrimEnd(';') + ';' + $RsyncDir } else { $RsyncDir }\r
+ [Environment]::SetEnvironmentVariable('Path', $new, 'Machine')\r
+ Write-Host " Added $RsyncDir to the machine PATH (restart shells / sshd to pick it up)."\r
+ # sshd caches the environment it was started with, so an already-running\r
+ # service would not see the new PATH until restarted.\r
+ if ((Get-Service sshd -ErrorAction SilentlyContinue).Status -eq 'Running') {\r
+ Restart-Service sshd\r
+ Write-Host ' Restarted sshd so it inherits the updated machine PATH.'\r
+ }\r
+ } else {\r
+ Write-Host " OK: $RsyncDir already in the machine PATH"\r
+ }\r
+\r
+ & $RsyncExe --version | Select-Object -First 1\r
+ } catch {\r
+ Write-Warning "rsync install failed: $($_.Exception.Message)"\r
+ Write-Warning "Download $RsyncAsset from https://github.com/$RsyncRepo/releases manually"\r
+ Write-Warning "and unpack it into $RsyncDir, keeping rsync.exe and ssh.exe together."\r
+ }\r
vilimpoc.org / repos / dotfiles / blobdiff