open-pr: avoid using system curl (because it can't do TLS v1.3)

[dscho]

The curl executable in C:\Windows\system32 exclusively uses Secure Channel as TLS backend. This is usually fine, except when one needs to talk to a TLS v1.3-only host and one is stuck with Windows prior to Windows 11 (where Secure Channel simply does not support TLS v1.3).

This happens to be exactly the case that caused the workflow run to fail that wanted to open a PR for OpenSSH v9.2p1.

Let's just use our own MINGW curl.exe instead.

[dscho]

This is the successful run that opened https://github.com/git-for-windows/MSYS2-packages/pull/80: https://github.com/git-for-windows/git-for-windows-automation/actions/runs/4079002007/jobs/7029893303

[rimrul]

The commit message of baa5ab4d01135286c5adb4439f3623dbab33294e is a little inacurate. The windows-latest images are currently Windows Server 2022, where schannel does support TLS 1.3 by default, but the system curl is v7.83.1 and curl only introduced support for TLS 1.3 via the schannel backend in v7.85.0

[dscho]

@rimrul thank you for your excellent review! I've fixed the issues you pointed out:

range-diff

* 1: baa5ab4 ! 1: c6fb563 open-pr: avoid using C:\Windows\system32\curl.exe ``````diff @@ Metadata ## Commit message ## open-pr: avoid using C:\Windows\system32\curl.exe - That `curl` version uses Secure Channel internally, which is limited to - TLS v1.2 on Windows versions before Windows 11. + That `curl` version uses Secure Channel internally, which supports TLS + v1.3 only since version 7.85.0, and this support requires Windows 11 + (see https://curl.se/changes.html#7_85_0). While we do run the workflow + in `windows-latest` hosted runners, which means Windows Server 2022, the + Server equivalent to Windows 11, the `curl.exe` in that Windows version + seems to be stuck at v7.83.1. That is a problem because we seem to be unable to access OpenSSH's CloudFlare CDN via anything below TLS v1.3, and this GitHub workflow @@ Commit message So let's use Git's own `curl.exe` (which can use OpenSSL, which in turn has no problems speaking TLS v1.3). + We do insist on using `/mingw64/bin/curl.exe` because + `/mingw64/bin/libcurl-4.dll` is already included in the `minimal` SDK + artifact (to allow `git fetch`/`git push` via HTTPS), whereas if we were + to use `/usr/bin/curl.exe` would require at least + `/usr/bin/msys-curl-4.dll` (and who knows what other dependencies) that + are not included in the `minimal` SDK. + Signed-off-by: Johannes Schindelin ## .github/workflows/open-pr.yml ## `````` * 2: f76696f = 2: 6bcba04 open-pr: avoid using the `setup-git-for-windows-sdk` Action * 3: 31f9a18 ! 3: 3b65b81 open-pr: cache the git-sdk-64 subset ``````diff @@ Commit message source archive, and something in `update-scripts/` needs to be added or to be adjusted. + The "cache git-sdk-64 subset" step is modeled after + https://github.com/actions/cache/#example-cache-workflow and caches the + git-sdk-64 subset in a `post` Action if there was no cache hit. + Signed-off-by: Johannes Schindelin ## .github/workflows/open-pr.yml ## @@ .github/workflows/open-pr.yml: jobs: - https://github.com/git-for-windows/git-sdk-64 .tmp + https://github.com/git-for-windows/git-sdk-64 .tmp && + echo "rev=$(git -C .tmp rev-parse HEAD)" >>$GITHUB_OUTPUT -+ - name: Cache git-sdk-64 subset ++ - name: cache git-sdk-64 subset + id: cache-g4w-sdk + uses: actions/cache@v3 + env: `````` * 4: 8ec1887 = 4: a858612 open-pr: special-case OpenSSH's version strings

[dscho]

@rimrul could you give this another review?

[rimrul]

LGTM