OpenSSL strategy?

[dscho]

I think we should rethink our openssl/mingw-w64-openssl strategy.

Currently we maintain packages in Git for Windows Pacman repository that shadow MSYS2's versions of the same package. There are two reasons for that:

1. Historically, MSYS2 used to lag behind OpenSSL versions quite a bit. In Git for Windows, we needed to equip our users with secure versions relatively quickly. So we started to shadow MSYS2's packages by building up to date versions mere days after the OpenSSL announcements, not weeks or months. This situation has changed, actually reversed. These days Git for Windows usually lags behind further than the MSYS2 project, which is very active, having gained enthusiastic contributors who do a wonderful job at updating packages.
2. Nowadays MSYS2 does not offer any i686 variants of the MSYS packages anymore. That matters because OpenSSH still links to OpenSSL, and even though Git for Windows no longer offers full 32-bit installers, it bundles OpenSSH in its i686 flavor of MinGit.

In the interest of avoiding duplicate work that competes with MSYS2, and instead work closely together with that fantastic project and use all of our time wisely, I'm considering whether we can stop building OpenSSL in Git for Windows.

For x86_64/aarch64, we could simply switch to MSYS2's packages. For i686, we could keep building our own versions and stay on the v3.5.* train, which is supposedly good until 2029:

@rimrul @mjcheetham thoughts?

[dscho]

Here is my plan: After Git for Windows v2.55.0, I'm going to drop OpenSSL from Git for Windows' Pacman repositories so that we'll inherit MSYS2's packages, and then we just go with what they ship (and we'll of course contribute our part in keeping their OpenSSL up to date).

For i686, we may still have to build OpenSSL v3.5.* until we stop supporting i686 altogether, seeing as http.sslBackend is a thing even in MinGit. But hopefully the CVEs in OpenSSL v3.5.* will die down a bit, after the Mythos-induced flurry.