Fix GitHub CI: hard-pin OpenSSL to tag openssl-3.6.0

[VladGud]

No description provided.

[VladGud]

Unfortunately, we will have to disable support for the master OpenSSL branch for now :/
We are working on updating the current gost-engine to support the upstream OpenSSL.

[chipitsine]

np

[VladGud]

Unfortunately, we will have to disable support for the master OpenSSL branch for now :/ We are working on updating the current gost-engine to support the upstream OpenSSL.

Also, we’ll need to disable the x86 build for now too, since the OpenSSL 3.6.0 build bug seems to be fixed only in upstream so far: openssl/openssl#28745

[chipitsine]

in theory we can move x86 jobs to scheduled (weekly?) ci in order not to forget.
but it will keep bothering by red builds

[VladGud]

in theory we can move x86 jobs to scheduled (weekly?) ci in order not to forget. but it will keep bothering by red builds

Yes, sure. But I have a counter-proposal: we can run all jobs in this file once a week including the master jobs. It may be unnecessary for the stable jobs, but it is useful for the master jobs.

[vt-alt]

Would be useful to know the reason why CI is disabled, except it's being "unfortunately".

[VladGud]

Would be useful to know the reason why CI is disabled, except it's being "unfortunately".

The main reason is that the engine architecture is being removed from upstream OpenSSL in the upcoming release. Our colleagues from the gost-engine project have politely indicated this as well (see their note here: openssl/openssl#29303 (comment)). As we understand it, the ENGINE interface will be completely removed in OpenSSL 4.0.

At the moment it is still possible to build against the OpenSSL master branch using the legacy interface by enabling OPENSSL_NO_DEPRECATED_3_0 (reference:
https://github.com/openssl/openssl/blob/ba4970afb5b60f022126b7fb3ee3c44cb9ceac8c/include/openssl/engine.h#L903C9-L903C34). However, we believe this is only a temporary workaround and will soon stop working, causing our CI tests to fail again.

We plan to update gost-engine (in particular the gost-provider) to remove its dependency on the legacy ENGINE interface, so that we can support upstream OpenSSL without workarounds.

[vt-alt]

Thanks for explanation. Would be good to have reason defined in the commit message. (Also, as I remember, only the low level algorithms are supported via gost provider, not the TLS level.)

[VladGud]

Thanks for explanation. Would be good to have reason defined in the commit message. (Also, as I remember, only the low level algorithms are supported via gost provider, not the TLS level.)

You are right that the provider interface itself focuses on low-level cryptographic operations rather than TLS logic. However, OpenSSL also provides a mechanism for providers to advertise additional metadata about their capabilities — so-called provider capabilities. These capabilities allow a provider to declare what algorithms, key types, or TLS groups it supports (see: https://docs.openssl.org/master/man7/provider-base/#tls-group-capability).

Using this mechanism (example:

engine/gost_prov_tls.c

Line 8 in 36ce16f

#define OSSL_TLS_GROUP_ID_gc256A 0x0022

), the gost-provider already defines the necessary TLS-related capabilities, and with our local patches it works with TLS 1.3 today.

We aim to achieve full TLS 1.3 support through the gost-provider without using the legacy ENGINE interface. TLS 1.2 support in the provider model will need more changes in gost-provider and in OpenSSL.

[VladGud]

in theory we can move x86 jobs to scheduled (weekly?) ci in order not to forget. but it will keep bothering by red builds

I set the master and x86 jobs to run weekly so we do not forget to fix them.

[chipitsine]

thanks!

I also concerned on couple of failures, but didn't have time to have a look

[VladGud]

thanks!

I also concerned on couple of failures, but didn't have time to have a look

These problems are caused by connection filtering on the Infotecs test server. The same commit passed the gcc test on my local setup: https://github.com/VladGud/engine/actions/runs/20169612752/job/57901586075. The results are unstable. You can try rerunning the failed tests a few times.