fix(ci): use FireDaemon OpenSSL zip on Windows

[matejk]

Summary

• Replace the winget-based ShiningLight install with FireDaemon's portable OpenSSL zip.
• Install into the job's RUNNER_TEMP sandbox so every run gets a clean copy.
• The zip includes the legacy provider (ossl-modules/legacy.dll) needed for DES-ECB and PKCS12 RC2/3DES PBE tests.

Why

The previous winget step broke because:

• winget returns non-zero exit when a package is already installed (winget should not error when installing the exact version of a package that is already installed microsoft/winget-cli#4262).
• The windows-2025 runner image ships an OpenSSL without the legacy provider, so even detecting the pre-installed copy would fail on DES-ECB / PKCS12 tests.
• PATH-based detection picked up libssl-3-x64.dll from MySQL (which ships its own earlier on PATH).
• msstore agreement prompts can interrupt winget list/install.

FireDaemon's distribution sidesteps all of this:

• Portable zip -- no installer, no registry, no admin.
• Includes ossl-modules/legacy.dll out of the box.
• Stable URL scheme, pinned version with automatic latest-patch detection.

Test plan

• Full windows-2025-msvc-cmake job passed on this branch: https://github.com/pocoproject/poco/actions/runs/24532002067/job/71717348644

[aleks-f]

we now also need SSH, see #5315.

SSH vcpkg installs both:

- name: Install libssh (vcpkg)
        shell: pwsh
        run: |
          vcpkg install libssh:x64-windows
          $root = "$env:VCPKG_INSTALLATION_ROOT\installed\x64-windows"
          "LIBSSH_ROOT_DIR=$root" | Out-File -FilePath $env:GITHUB_ENV -Append
          Add-Content $env:GITHUB_PATH "$root\bin"

[matejk]

we now also need SSH, see #5315.

SSH vcpkg installs both:

- name: Install libssh (vcpkg)
        shell: pwsh
        run: |
          vcpkg install libssh:x64-windows
          $root = "$env:VCPKG_INSTALLATION_ROOT\installed\x64-windows"
          "LIBSSH_ROOT_DIR=$root" | Out-File -FilePath $env:GITHUB_ENV -Append
          Add-Content $env:GITHUB_PATH "$root\bin"

Problem on GitHub runners was that they are shared and there were many OpenSSL library present on the runner (some with and some without development files). Installing with vcpkg did not resolve all of the issues.

Using a zip file where it is possible to control the files that are going to be used was the most stable way to do it.

[aleks-f]

Problem on GitHub runners was that they are shared and there were many OpenSSL library present on the runner (some with and some without development files). Installing with vcpkg did not resolve all of the issues.

Using a zip file where it is possible to control the files that are going to be used was the most stable way to do it.

vcpkg can be installed in a directory, without affecting anything system-wide.

I don't care one way or the other, as long as we have ssh covered and don't end up again with multiple openssl copies. to me, vcpkg installing ssh/openssl in a local directory seems like an optimal solution

[matejk]

I'll merge this now to have CI working on Windows.

[aleks-f]

I'll merge this now to have CI working on Windows.

from what I am seeing, windows ci with vcpkg works just fine: #5315

poco/.github/workflows/ci.yml

Lines 642 to 648 in 4b8b7bd

	- name: Install libssh (vcpkg)
	shell: pwsh
	run: |
	vcpkg install libssh:x64-windows
	$root = "$env:VCPKG_INSTALLATION_ROOT\installed\x64-windows"
	"LIBSSH_ROOT_DIR=$root" | Out-File -FilePath $env:GITHUB_ENV -Append
	Add-Content $env:GITHUB_PATH "$root\bin"

[matejk]

Until it suddenly doesn't because there are multiple installations on the worker, including such without development files. I created test job that discovered more than five instances of OpenSSL files in the path on the worker and installation from shining light without development files. 🤷

[aleks-f]

Until it suddenly doesn't because there are multiple installations on the worker, including such without development files. I created test job that discovered more than five instances of OpenSSL files in the path on the worker and installation from shining light without development files. 🤷

ok, let's not make a mystery out of this. how can there be multiple vcpkg installations when vcpkg puts it always in C:\vcpkg? in which directories exactly were those multiple installations? the only time I have seen that is when ShiningLight version increases and the old one remains left behind. vcpkg will always put it in the same place and it can also put it wherever we want. we can also create a script that checks what is there, just like we have in devs repo

if you have a different solution for ssh, let me know. otherwise it will have to be vcpkg

[aleks-f]

The problem is most likely having more than one ssl installation, I have seen that on our windows ci machine with vcpkg and ShiningLight. The same effect that was achieved with merging this branch would have been achieved with merging vcpkg in main. And if there is ever another ci with ShiningLight triggered, it will happen again.