mingw-w64-openssl: update to 3.2.0

[gitforwindowshelper]

This closes git-for-windows/git#4703

[dscho]

Hmm. #96 did not have test failures. From a cursory look, it seems as if there were sizeof(long) != 8 problems, i.e. problems where the code expects long to be 64-bit but it's 32-bit on Windows.

[rimrul]

If I read the logs correctly it failed only this test:

Test Summary Report
2023-12-11T11:43:23.3604664Z -------------------
2023-12-11T11:43:23.3605292Z 01-test_symbol_presence.t (Wstat: 512 (exited 2) Tests: 3 Failed: 2)
2023-12-11T11:43:23.3606226Z Failed tests: 2-3
2023-12-11T11:43:23.3606628Z Non-zero exit status: 2

And on #96 the logs say (emphasis mine)

2023-10-25T15:38:25.3559145Z 01-test_symbol_presence.t .......... skipped: This is unsupported on MSYS, MinGW or MSWin32

Whereas the logs on this PR say (emphasis mine)

01-test_symbol_presence.t ...............
2023-12-11T11:21:09.7113592Z # The results of this test will end up in test-runs/test_symbol_presence
2023-12-11T11:21:09.7115252Z # NOTE: developer test! It's possible that it won't run on your
2023-12-11T11:21:09.7116488Z # platform, and that's perfectly fine. This is mainly for developers
2023-12-11T11:21:09.7117627Z # on Unix to check that our shared libraries are consistent with the
2023-12-11T11:21:09.7118737Z # ordinals (util/*.num in the source tree), and that our static libraries
2023-12-11T11:21:09.7119911Z # don't share symbols, something that should be a good enough check for
2023-12-11T11:21:09.7120708Z # the other platforms as well.
2023-12-11T11:21:09.7121154Z 1..3
2023-12-11T11:21:09.7121630Z # Number of lines in @stlib_lines before massaging: 28123
2023-12-11T11:21:09.7122407Z # Number of lines in @shlib_lines before massaging: 0
2023-12-11T11:21:09.7123164Z # Number of lines in @def_lines before massaging: 5515
2023-12-11T11:21:09.7123929Z # Number of lines in @stlib_lines after massaging: 7441
2023-12-11T11:21:09.7124685Z # Number of lines in @shlib_lines after massaging: 0
2023-12-11T11:21:09.7125430Z # Number of lines in @def_lines after massaging: 5496
2023-12-11T11:21:09.7126193Z # Number of lines in @stlib_lines before massaging: 5186
2023-12-11T11:21:09.7127094Z # Number of lines in @shlib_lines before massaging: 0
2023-12-11T11:21:09.7127814Z # Number of lines in @def_lines before massaging: 581
2023-12-11T11:21:09.7128474Z # Number of lines in @stlib_lines after massaging: 1697
2023-12-11T11:21:09.7128931Z # Number of lines in @shlib_lines after massaging: 0
2023-12-11T11:21:09.7129357Z # Number of lines in @def_lines after massaging: 574
2023-12-11T11:21:09.7129868Z ok 1 - checking no duplicate symbols in static libraries
2023-12-11T11:21:09.7130283Z # The following symbols are missing in crypto:

Which I would understand as this test not being expected to pass on Windows.

[rimrul]

2023-10-25T15:38:25.3559145Z 01-test_symbol_presence.t .......... skipped: This is unsupported on MSYS, MinGW or MSWin32

openssl/openssl#20331 changed this test to only skip if it can't find nm and I'm afraid it's picking up Msys2 nm from /usr/bin/nm.exe, which probably doesn't handle MINGW libraries properly.

[rimrul]

apparently our /mingw64/bin/nm.exe insists that /mingw64/bin/libssl-3-x64.dll (and /mingw64/bin/libcurl-4.dll and /mingw64/bin/libexpat-1.dll) contains

no symbols

[rimrul]

apparently our /mingw64/bin/nm.exe insists that /mingw64/bin/libssl-3-x64.dll (and /mingw64/bin/libcurl-4.dll and /mingw64/bin/libexpat-1.dll) contains

no symbols

That might be the result of cv2pdb.

[rimrul]

When I remove the cv2pdb parts from PKGBUILD, I run into the next problems. Our nm keeps saying no symbols when called with -D. When I patch https://github.com/openssl/openssl/blob/master/test/recipes/01-test_symbol_presence.t#L68 to just call nm -Pg instead of nm -DPg the test is slightly happier, but still complains about 3 missing symbols in crypto and a bunch of extra symbols in crypto and then exits before completing all subtests.

Maybe we should just change

MINGW-packages/mingw-w64-openssl/PKGBUILD

Line 134 in 4882834

make VERBOSE=1 test

to

make VERBOSE=1 TESTS=-01-test_symbol_presence.t test

[dscho]

I am tempted to suggest a patch to simply force-skip this cumbersome test.

[rimrul]

This test failure is probably the same as some of the issues reported in openssl/openssl#23046

[rimrul]

I am tempted to suggest a patch to simply force-skip this cumbersome test.

We might need the same workaround for git-for-windows/MSYS2-packages#137

[rimrul]

/deploy

The i686/x86_64 and the arm64 workflow runs were started.

[rimrul]

2023-12-15T09:47:15.8176886Z + echo '-openssl-3.2.0-1-any.pkg.tar.xz not yet deployed, as expected'
2023-12-15T09:47:15.8181123Z -openssl-3.2.0-1-any.pkg.tar.xz not yet deployed, as expected

Not the reason for this failure to deploy, but definitely slightly broken.

[rimrul]

Oh, the failing part is x86, that explains why

PR build / build (mingw-w64-openssl) (pull_request)

doesn't fail.

[rimrul]

        # Subtest: convert_asn1_to_time_t
        1..5
        ok 63 - iteration 1
        ok 64 - iteration 2
        ok 65 - iteration 3
        ok 66 - iteration 4
        # ERROR: (time_t) 'testdateutc == asn1_to_utc[idx].expected' failed @ ../openssl-3.2.0/test/asn1_time_test.c:436
        # [7001010000-1Z] compared to [7001010000-1Z]
        # INFO:  @ ../openssl-3.2.0/test/asn1_time_test.c:437
        # ossl_asn1_string_to_time_t (INVALID) failed: expected -1, got -1
        # 
        # OPENSSL_TEST_RAND_SEED=1702635616
        not ok 67 - iteration 5
    # OPENSSL_TEST_RAND_SEED=1702635616
    not ok 4 - convert_asn1_to_time_t
../../util/wrap.pl ../../test/asn1_time_test.exe => 1
not ok 1 - running asn1_time_test

expected -1, got -1

Something is definitely broken here.

[rimrul]

expected -1, got -1

Something is definitely broken here.

It's probably test_time_t_eq() that's broken on MINGW32. I've modified https://github.com/openssl/openssl/blob/master/test/test_test.c#L196 to two hardcoded (time_t)-1s instead of (time_t)10 and it's now upset at them allegedly not being equal.

 ERROR: (time_t) '(time_t)-1 == (time_t)-1' failed @ ../openssl-3.2.0/test/test_test.c:196
    # [7001010000-1Z] compared to [7001010000-1Z]
# FATAL: TEST_time_t_eq((time_t)-1, (time_t)-1) != 1
    # OPENSSL_TEST_RAND_SEED=1704304651
    not ok 8 - test_time_t

[rimrul]

7001010000-1Z

That little -1 is our issue. gmtime() in MINGW32 can't handle being passed (time_t)-1 (or probably any negative value) it produces a bizare struct tm.

tm_year: 70 tm_mon: 0 tm_mday: 1
tm_hour: 0 tm_min: 0 tm_sec: -1
tm_wday: 4 tm_yday: 0 tm_isdst: 0

whereas the expected result from MINGW64 looks like this:

tm_year: 69 tm_mon: 11 tm_mday: 31
tm_hour: 23 tm_min: 59 tm_sec: 59
tm_wday: 4 tm_yday: 364 tm_isdst: 0

ossl_asn1_time_from_tm() then basically just prints most of those values into one big string, but the - from the negative value in tm_sec confuses ossl_asn1_time_to_tm() into thinking the -1Z is timezone information when only the Z is actually supposed to be timezone information. It then fails to parse that "timezone information" which ends up causing test_time_t_eq() to fail.

[rimrul]

/deploy

The i686/x86_64 and the arm64 workflow runs were started.

[rimrul]

/add relnote

The workflow run was started

[rimrul]

I'll deploy the CLANGARM64 version once we fix the azure issue that's currently stopping us from spinning up ARM runners.

[dscho]

Sorry for being less responsive than usual... 😞

[rimrul]

No harm done. People are sometimes busy.