Build with OpenSSL backend on Windows/MSVC fails

[maxirmx]

We don't test building OpenSSL on MSVC, but it doesn't work. The CMake configuration pass fails to create a test program that finds available OpenSSL functions.

(not sure how in the case described at https://github.com/rnpgp/rnp/issues/2020 build procedure was able to get so far)

[maxirmx]

@ronaldtse @ni4 Do we need it (openssl support on Windows) ? Thanks

[ni4]

@maxirmx I think that we should have it. If you'll post error log for opensslfeatures.c (as I understand problem is in it) I can suggest fixes. Don't have access to Windows machine with MSVC :-(

[maxirmx]

@ni4 So far it looks like CMake issue. It just cannot build test program on Windows because it applies unix-style script If I face some real openssl issues I will publish it Thank you

[ValeV008]

We don't test building OpenSSL on MSVC, but it doesn't work. The CMake configuration pass fails to create a test program that finds available OpenSSL functions.

(not sure how in the case described at #2020 build procedure was able to get so far)

Please see my comment https://github.com/rnpgp/rnp/issues/2020#issuecomment-1486523198, I added the git diff patch showing source code changes.

[maxirmx]

@ni4 Test _test_backendversion The last assert

        backen_prog_ext = shutil.which(backend_prog)
        if backen_prog_ext is not None:
            ret, out, _ = run_proc(backen_prog_ext, ['version'])
            self.assertEqual(ret, 0)
            self.assertIn(match.group(1), out)

Actually it tests that 'the first choice' openssl or botan executable has the same version that the library that was used to build rnp It is reasonable assumtion but not always valid. For example, github Windows runner has two versions of openssl installed -- the first in gi msys environment; the second in vcpkg environment and git version has to be the first in the PATH while we are building against something different.

I propose we just delete this assertion against executable version.

[maxirmx]

@ni4 In Windows environment I observe the following failure

======================================================================
FAIL: test_sym_encryption_s2k_msec (__main__.Encryption.test_sym_encryption_s2k_msec)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\rnp\rnp\src\tests\cli_tests.py", line 4021, in test_sym_encryption_s2k_msec
    self.assertGreaterEqual(iters100msec, iters10msec)
AssertionError: 278528 not greater than or equal to 589824
----------------------------------------------------------------------

It is unstable and unpredictable. The values vary, of course. I believe it depends on GHA load. It looke like if GHA is busy it becomes more probable. I cannot reproducr it locally. Any suggestions how to address it ?

[ni4]

@maxirmx

Test test_backend_version

Yeah, I got hit with this on macOS as well, when use non-standard OpenSSL version. We could go deeper and check via ldd or similar apps to which OpenSSL rnp is linked, or ignore for now adding the issue about the ldd to the tracker.

It is unstable and unpredictable. The values vary, of course.

Yeah, that also fails sometimes for Linuxes. I guess we may ignore the result, but leave the test (making sure that some value is still calculated).