X-Git-Url: https://vilimpoc.org/repos/dotfiles/blobdiff_plain/2e281421e8cccce19bc1b43bb5bdd7d877870b4e..649b04df2966260f38a18d5225a68bd4e0896b95:/setup-windows-no-uac.ps1?ds=inline diff --git a/setup-windows-no-uac.ps1 b/setup-windows-no-uac.ps1 index e1d5beb..5d713c3 100644 --- a/setup-windows-no-uac.ps1 +++ b/setup-windows-no-uac.ps1 @@ -12,10 +12,20 @@ What this installs / configures: - WinMerge on the user PATH + - vswhere.exe on the user PATH: the Visual Studio installer puts it in + %ProgramFiles(x86)%\Microsoft Visual Studio\Installer, which nothing adds + to the PATH, so build scripts (and VsDevCmd.bat itself) complain that + 'vswhere.exe' is not recognized - BinSkim (binary hardening analyzer) in %LOCALAPPDATA%\Programs\BinSkim, - on the user PATH - - Global git identity, and core.sshCommand pointed at the Windows OpenSSH - client so git shares the Windows ssh-agent + on the user PATH. The package has no win-arm64 build, so on ARM64 this is + the x64 tool under emulation - which analyses ARM64 binaries fine, since it + only reads their headers. + - Global git identity, and core.sshCommand pointed at a Win32-OpenSSH + client so git shares the Windows ssh-agent: the fast ssh.exe the elevated + half unpacks beside rsync.exe if it is there, the in-box one otherwise + - An architecture audit: the real PE machine type of every tool this box + provisions, resolved the way a shell would. Informational, never fatal. + Anything running emulated without a listed reason is called out. FILL IN $GitUserName / $GitUserEmail below before the first run. @@ -30,12 +40,18 @@ param( # for several, dot-call the script or use -Command: # .\setup-windows-no-uac.ps1 -Skip BinSkim,GitConfig # powershell -File .\setup-windows-no-uac.ps1 -Skip BinSkim - [ValidateSet('WinMerge', 'BinSkim', 'GitConfig')] + [ValidateSet('WinMerge', 'VsWhere', 'BinSkim', 'GitConfig', 'ArchAudit')] [string[]] $Skip = @() ) $ErrorActionPreference = 'Stop' +# Host architecture. RuntimeInformation rather than PROCESSOR_ARCHITECTURE: an +# emulated PowerShell reports the emulated architecture in the environment +# variable while this API reports the real one. Values: X64, Arm64, X86. +$HostArch = [Runtime.InteropServices.RuntimeInformation]::OSArchitecture.ToString() +$IsArm64 = ($HostArch -eq 'Arm64') + # --- Global git identity: FILL THESE IN BEFORE RUNNING --- # Left empty, Set-GlobalGitConfig skips the identity and says so, rather than # stamping a placeholder onto your commits. Leaving them empty is a legitimate @@ -48,6 +64,11 @@ $GitUserEmail = '' # e.g. 'ada@example.com' $BinSkimPackage = 'microsoft.codeanalysis.binskim' $BinSkimDir = Join-Path $env:LOCALAPPDATA 'Programs\BinSkim' +# Where the elevated half puts rsync.exe and the ssh.exe it ships with. Only +# read here, to prefer that ssh.exe for git - keep it in step with $RsyncDir in +# setup-windows-with-uac.ps1 if you move the install. +$RsyncDir = 'C:\Tools\rsync' + function Write-Step([string]$Msg) { Write-Host "`n==> $Msg" -ForegroundColor Cyan } @@ -84,14 +105,40 @@ function Add-WinMergeToUserPath { Add-ToUserPath $dir } +function Add-VsWhereToUserPath { + # vswhere.exe is how scripts locate Visual Studio (MSBuild, VsDevCmd.bat, + # the Windows SDK), and the VS installer drops it in a fixed directory that + # is never on the PATH. VsDevCmd.bat itself prints "'vswhere.exe' is not + # recognized" on every run without it. The directory is fixed by contract + # (32-bit Program Files, no version in the path), so there is nothing to + # search for: if it is missing, Visual Studio is not installed. + Write-Step 'vswhere on the user PATH' + $dir = Join-Path ${env:ProgramFiles(x86)} 'Microsoft Visual Studio\Installer' + if (-not (Test-Path (Join-Path $dir 'vswhere.exe'))) { + Write-Warning "vswhere.exe not found in $dir (no Visual Studio installer present); user PATH unchanged." + return + } + Add-ToUserPath $dir +} + function Install-BinSkim { # BinSkim checks the exact mitigations the native project enables in # CMakeLists.txt (CFG/XFG, CET, ASLR/HighEntropyVA, DEP, /GS, stack cookies, - # DEPENDENTLOADFLAG, ...). The NuGet package ships a self-contained win-x64 - # build, so this needs no .NET SDK/runtime: the .nupkg is a zip - extract the - # win-x64 tool folder and put it on the PATH. After restarting the shell: + # DEPENDENTLOADFLAG, ...). The NuGet package ships a self-contained build, so + # this needs no .NET SDK/runtime: the .nupkg is a zip - extract the tool + # folder for this architecture and put it on the PATH. After restarting the + # shell: # binskim analyze path\to\your.exe # + # ARCHITECTURE. The package currently publishes win-x64 only (its other RIDs + # are linux-x64, linux-arm64 and osx-x64) - there is no win-arm64 build. So on + # ARM64 this installs the x64 tool and it runs under emulation. That is a + # slowdown and nothing more: BinSkim READS PE headers and load configs, so the + # architecture of the binaries it analyses is independent of its own - an + # emulated x64 BinSkim checks ARM64 binaries perfectly well. $BinSkimRids is + # ordered preference, so if a win-arm64 build ever ships, an ARM64 box picks + # it up with no further change here. + # # VERSION CHECK FIRST. The .nupkg is a large download (well over 100 MB), so # ask NuGet what the newest stable version is BEFORE fetching anything, and # skip the download entirely when the installed copy already matches. @@ -156,10 +203,22 @@ function Install-BinSkim { -Uri "https://api.nuget.org/v3-flatcontainer/$BinSkimPackage/$latest/$BinSkimPackage.$latest.nupkg" Expand-Archive -Path $zip -DestinationPath $tmp -Force - $src = Get-ChildItem -Path $tmp -Recurse -Filter 'BinSkim.exe' | - Where-Object { $_.FullName -match 'win-x64' } | - Sort-Object FullName | Select-Object -Last 1 - if (-not $src) { throw 'BinSkim.exe (win-x64) not found in package.' } + # Native RID first, emulatable one second. Matched against the path + # so the newest matching tools\\\ folder wins, as before. + $BinSkimRids = if ($IsArm64) { @('win-arm64', 'win-x64') } else { @('win-x64') } + $src = $null + $allExes = Get-ChildItem -Path $tmp -Recurse -Filter 'BinSkim.exe' + foreach ($rid in $BinSkimRids) { + $src = $allExes | Where-Object { $_.FullName -match [regex]::Escape($rid) } | + Sort-Object FullName | Select-Object -Last 1 + if ($src) { + if ($rid -ne $BinSkimRids[0]) { + Write-Host " No $($BinSkimRids[0]) build in the package; using $rid (runs under emulation)." -ForegroundColor Yellow + } + break + } + } + if (-not $src) { throw "BinSkim.exe ($($BinSkimRids -join ' / ')) not found in package." } # Replace wholesale rather than merging over the old tree, so files # dropped between releases don't linger. @@ -211,18 +270,67 @@ function Set-GlobalGitConfig { Write-Host " identity: $GitUserName <$GitUserEmail>" } - # --- Make git use the Windows OpenSSH client --- + # --- Make git use a Win32-OpenSSH client --- # Git for Windows ships its own MSYS2 ssh.exe and prefers it, and that client # cannot reach the Windows ssh-agent service that the elevated half enables: # Win32-OpenSSH publishes the agent on a named pipe the MSYS2 build does not # speak. So keys added with `ssh-add` from PowerShell stay invisible to git, # and a push falls back to hunting for a key file and prompting for its - # passphrase. Pointing core.sshCommand at the in-box ssh.exe gives git the - # same client, the same agent, and the same %USERPROFILE%\.ssh\config as + # passphrase. Pointing core.sshCommand at a Win32-OpenSSH ssh.exe gives git + # the same client, the same agent, and the same %USERPROFILE%\.ssh\config as # `ssh` from an ordinary shell. - $winSsh = Join-Path $env:WINDIR 'System32\OpenSSH\ssh.exe' - if (-not (Test-Path $winSsh)) { - Write-Warning "No Windows OpenSSH client at $winSsh. Add the 'OpenSSH Client' optional feature and re-run; until then git uses its own bundled ssh.exe, which cannot see keys held by the Windows ssh-agent service." + # + # Two of those are on the box, and the one beside rsync.exe is preferred. + # It is the same client from the same source, with the same ~/.ssh, agent + # and known_hosts, built with a pump on its stdin: the in-box one reads + # stdin 3KB at a time, which holds anything git PUSHES to ~17MB/s however + # fast the link is. It only exists once the elevated half has run, so the + # in-box client stays the fallback - and on a first provisioning run from + # setup-windows.bat it is the elevated half that runs first, so the fast one + # is normally already there. + # + # ON ARM64 the preference is the same but the trade is different: that build + # is published for x64 only, so it is the EMULATED client being preferred over + # a native ARM64 one. It is still the right pick when it runs - a push is + # bounded by the socket, not by emulated CPU, so lifting the 3KB stdin cap + # wins by far more than emulation costs - but it may well not run at all, + # because it links against a System32 libcrypto.dll that is an ARM64 binary + # here. That is exactly why candidates are tried by RUNNING them below rather + # than by Test-Path, and why the elevated half deletes that ssh.exe outright + # when it will not start. Either way this lands on a working client. + $sshCandidates = @( + (Join-Path $RsyncDir 'ssh.exe'), + (Join-Path $env:WINDIR 'System32\OpenSSH\ssh.exe') + ) + $winSsh = $null + foreach ($cand in $sshCandidates) { + if (-not (Test-Path $cand)) { continue } + # Run it, rather than just believing the file is there: the build beside + # rsync.exe links against the libcrypto.dll the OpenSSH Client capability + # puts in System32, and without that capability it is a binary that does + # not start. Better to find that out here than on the next `git push`. + # + # EAP back to Continue for the call: ssh -V writes its version to + # STDERR, and with $ErrorActionPreference = 'Stop' a native command's + # stderr becomes a terminating RemoteException - so the working client + # would look like the broken one. + $prevEap = $ErrorActionPreference + $ErrorActionPreference = 'Continue' + $version = $null + # Clear the exit code first, explicitly at global scope. An exe that + # cannot start at all - the missing-libcrypto case - throws here without + # ever setting one, and the stale 0 from the last native command that DID + # run would otherwise read as success. $global: because a bare assignment + # would make a local copy that the native call then does not update. + $global:LASTEXITCODE = $null + try { $version = (& $cand -V 2>&1 | Select-Object -First 1) } catch { } + finally { $ErrorActionPreference = $prevEap } + if ($LASTEXITCODE -eq 0) { $winSsh = $cand; break } + $why = if ($null -eq $LASTEXITCODE) { 'it would not start' } else { "exit $LASTEXITCODE" } + Write-Warning "$cand did not run ($why)$(if ($version) { ": $version" })" + } + if (-not $winSsh) { + Write-Warning "No working Win32-OpenSSH client found (looked in $($sshCandidates -join ', ')). Add the 'OpenSSH Client' optional feature and re-run; until then git uses its own bundled ssh.exe, which cannot see keys held by the Windows ssh-agent service." return } # Forward slashes on purpose: git parses core.sshCommand with shell quoting @@ -230,11 +338,160 @@ function Set-GlobalGitConfig { $value = $winSsh -replace '\\', '/' & $git config --global core.sshCommand $value Write-Host " core.sshCommand: $value" + Write-Host " $version" +} + +function Get-PEMachine { + # Architecture of a PE, read straight from the COFF header: the 2 bytes at + # the e_lfanew offset + 4. Cheap, and it answers the only question that + # matters here - would this exe run natively, or through emulation? + # + # Deliberately NOT Get-Command's .FileVersionInfo or the package metadata: + # a multi-architecture package (Sysinternals) ships every build in one zip + # under different names, and an installer's own metadata says nothing about + # which binary got laid down. The file itself cannot be wrong. + param([string]$Path) + if (-not (Test-Path $Path)) { return $null } + try { + $fs = [IO.File]::OpenRead($Path) + $br = New-Object IO.BinaryReader($fs) + try { + $fs.Seek(0x3c, 'Begin') | Out-Null + $pe = $br.ReadInt32() + if ($pe -le 0 -or $pe -gt ($fs.Length - 6)) { return 'not-PE' } + $fs.Seek($pe + 4, 'Begin') | Out-Null + switch ($br.ReadUInt16()) { + 0x8664 { 'x64' } + 0xAA64 { 'ARM64' } + 0x014c { 'x86' } + 0x01c4 { 'ARM32' } + default { 'unknown' } + } + } finally { $br.Close(); $fs.Close() } + } catch { $null } +} + +function Invoke-ArchAudit { + # Report the actual architecture of the tools this box provisions, resolved + # the way a shell would (PATH first, then the usual install roots), so what + # is printed is what you would really run. + # + # This exists because "winget installed it" does not mean "you got the native + # build", and the gap is not always where you would guess - Visual Studio's + # own bundled ninja.exe is x64 even on an ARM64 host. A per-run audit turns + # that from something you trip over into something the log tells you. + # + # Purely informational: it never fails the run. On x64 everything is expected + # to be x64 and the output is dull; the value is on ARM64, where each line is + # either native or a known, listed exception. + Write-Step "Architecture audit (host: $HostArch)" + + # Tools with no native ARM64 build available anywhere, with the reason. These + # print as expected rather than as problems - see the README's ARM64 section. + $KnownEmulated = @{ + 'BinSkim.exe' = 'NuGet package publishes win-x64 only; it reads PE headers, so it still analyses ARM64 binaries' + 'rsync.exe' = 'no ARM64 asset published; transfer is socket-bound, not CPU-bound' + 'OpenCppCoverage.exe' = 'x86/x64 only, and cannot instrument ARM64 binaries - run coverage against the x64 build' + 'nasm.exe' = 'x86/x86-64 assembler by definition; ARM64 uses armasm64.exe from MSVC' + 'iperf3.exe' = 'no ARM64 build published; network-bound anyway' + 'py.exe' = 'python.org ships the launcher shim as x86; it execs the native python.exe' + 'vswhere.exe' = 'Microsoft ships x86 only; runs once per script' + } + + # Fixable cases: a native build DOES exist, something just resolved ahead of + # it. Printed with the finding so the log carries the remedy, not just the + # complaint. + # + # ninja is the one that actually bites. Visual Studio bundles an x64 ninja.exe + # even on ARM64, and VsDevCmd.bat PREPENDS the VS directories to PATH - so + # inside a Developer Command Prompt the emulated one wins over the native + # winget copy, and that is exactly the shell C++ builds happen in. It matters + # more than a one-off tool because ninja is re-invoked for every edge in the + # build graph. + $Remedies = @{ + 'ninja.exe' = 'Visual Studio bundles an x64 ninja and VsDevCmd prepends its directory. Pass -DCMAKE_MAKE_PROGRAM to the native one (winget install Ninja-build.Ninja), or put its directory ahead of the VS one.' + 'cmake.exe' = 'Install the native build with: winget install Kitware.CMake' + 'clang-cl.exe' = 'Install the upstream native LLVM with: winget install LLVM.LLVM' + } + + $vs = $null + $vsWhereExe = Join-Path ${env:ProgramFiles(x86)} 'Microsoft Visual Studio\Installer\vswhere.exe' + if (Test-Path $vsWhereExe) { + $vs = & $vsWhereExe -products '*' -property installationPath -format value | Select-Object -First 1 + } + + # name -> extra candidate paths searched when the name is not on the PATH. + $targets = [ordered]@{ + 'git.exe' = @("$env:LOCALAPPDATA\Programs\Git\cmd\git.exe", (Join-Path $env:ProgramFiles 'Git\cmd\git.exe')) + 'python.exe' = @() + 'py.exe' = @("$env:WINDIR\py.exe") + 'pwsh.exe' = @() + 'cmake.exe' = @((Join-Path $env:ProgramFiles 'CMake\bin\cmake.exe')) + 'ninja.exe' = @() + 'clang-cl.exe' = @((Join-Path $env:ProgramFiles 'LLVM\bin\clang-cl.exe')) + 'dotnet.exe' = @((Join-Path $env:ProgramFiles 'dotnet\dotnet.exe')) + 'WinMergeU.exe' = @((Join-Path $env:ProgramFiles 'WinMerge\WinMergeU.exe'), (Join-Path ${env:ProgramFiles(x86)} 'WinMerge\WinMergeU.exe')) + 'BinSkim.exe' = @((Join-Path $BinSkimDir 'BinSkim.exe')) + 'rsync.exe' = @((Join-Path $RsyncDir 'rsync.exe')) + 'ssh.exe' = @((Join-Path $env:WINDIR 'System32\OpenSSH\ssh.exe')) + 'nasm.exe' = @() + 'iperf3.exe' = @() + 'OpenCppCoverage.exe' = @((Join-Path $env:ProgramFiles 'OpenCppCoverage\OpenCppCoverage.exe'), (Join-Path ${env:ProgramFiles(x86)} 'OpenCppCoverage\OpenCppCoverage.exe')) + 'vswhere.exe' = @($vsWhereExe) + 'xperf.exe' = @((Join-Path ${env:ProgramFiles(x86)} 'Windows Kits\10\Windows Performance Toolkit\xperf.exe')) + } + if ($vs) { + $targets['MSBuild.exe'] = @((Join-Path $vs 'MSBuild\Current\Bin\arm64\MSBuild.exe'), (Join-Path $vs 'MSBuild\Current\Bin\MSBuild.exe')) + # The MSVC and VS-Clang compilers, under whichever MSVC version is present. + $msvc = Get-ChildItem (Join-Path $vs 'VC\Tools\MSVC') -Directory -ErrorAction SilentlyContinue | + Sort-Object Name | Select-Object -Last 1 + if ($msvc) { + $hostDir = if ($IsArm64) { 'Hostarm64\arm64' } else { 'Hostx64\x64' } + $targets['cl.exe (MSVC)'] = @((Join-Path $msvc.FullName "bin\$hostDir\cl.exe")) + } + $llvmHost = if ($IsArm64) { 'ARM64\bin' } else { 'x64\bin' } + $targets['clang-cl.exe (VS)'] = @((Join-Path $vs "VC\Tools\Llvm\$llvmHost\clang-cl.exe")) + } + + $native = if ($IsArm64) { 'ARM64' } else { 'x64' } + $unexpected = @() + foreach ($name in $targets.Keys) { + # PATH first - that is the binary a build would actually invoke - then the + # explicit candidates. The bare exe name is stripped of any " (label)". + $exe = ($name -split ' ')[0] + $path = (Get-Command $exe -ErrorAction SilentlyContinue | + Select-Object -First 1).Source + if (-not $path) { $path = $targets[$name] | Where-Object { $_ -and (Test-Path $_) } | Select-Object -First 1 } + if (-not $path) { Write-Host (" {0,-22} {1}" -f $name, '- not installed') -ForegroundColor DarkGray; continue } + + $mach = Get-PEMachine $path + if (-not $mach) { continue } + if ($mach -eq $native) { + Write-Host (" {0,-22} {1,-6} native" -f $name, $mach) -ForegroundColor Green + } elseif ($KnownEmulated.ContainsKey($exe)) { + Write-Host (" {0,-22} {1,-6} expected: {2}" -f $name, $mach, $KnownEmulated[$exe]) -ForegroundColor DarkGray + } else { + Write-Host (" {0,-22} {1,-6} NOT NATIVE - $path" -f $name, $mach) -ForegroundColor Yellow + if ($Remedies.ContainsKey($exe)) { + Write-Host (" {0,-22} {1,-6} -> {2}" -f '', '', $Remedies[$exe]) -ForegroundColor Yellow + } + $unexpected += "$name ($mach)" + } + } + + if ($unexpected) { + Write-Warning "Running under emulation with no listed reason: $($unexpected -join ', ')." + Write-Warning 'If a native build exists, prefer it (see the -> lines above); otherwise add it to $KnownEmulated with the reason.' + } else { + Write-Host ' Everything resolved to a native build, or to a listed exception.' -ForegroundColor Green + } } # --------------------------------------------------------------------------- # Main # --------------------------------------------------------------------------- +Write-Host "Host architecture: $HostArch" -ForegroundColor Cyan + if (([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole( [Security.Principal.WindowsBuiltInRole]::Administrator)) { Write-Warning 'Running elevated. The user PATH and .gitconfig changes below will apply to the administrator profile, not yours.' @@ -242,8 +499,12 @@ if (([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]:: $steps = [ordered]@{ WinMerge = { Add-WinMergeToUserPath } + VsWhere = { Add-VsWhereToUserPath } BinSkim = { Install-BinSkim } GitConfig = { Set-GlobalGitConfig } + # Last on purpose: it reports on what the steps above (and the winget installs + # in setup-windows.bat) actually put on the box. + ArchAudit = { Invoke-ArchAudit } } $failed = @()