CI: Simplify kryoptic build

[Jakuje]

Description

Kryoptic supports linking against system OpenSSL, which should be much faster than rebuilding the whole OpenSSL.

I do not think we need the build against specific OpenSSL version now.

Reviewer's checklist:

• Any issues marked for closing are addressed
• There is a test suite reasonably covering new functionality or modifications
• This feature/change has adequate documentation added
• Code conform to coding style that today cannot yet be enforced via the check style test
• Commits have short titles and sensible commit messages
• Coverity Scan has run if needed (code PR) and no new defects were found

[Jakuje]

Ok, not ready yet. The tls test fails now with kryoptic when we force all operations to the token

########################################
## Forcing the provider for all server operations


## Run sanity test with default values (RSA)
...
80C2517DC77F0000:error:40800054:pkcs11:p11prov_GetOperationState:reason(84):../src/interface.gen.c:335:Error returned by C_GetOperationState

Not sure if this is the relevant error or something else got broken (or the dynamic feature messes up the openssl context). Will have to investigate further.

[simo5]

I pushed a commit that resolves most of the TLS errors, which were due to us "poisoning" the openssl error stack emitting suprious messages when a pkcs#11 API call was failing.

Sometimes those failures are expected and are properly handled, but the OpenSSL TLS code considers any dirty stack to be a fatal error even if the functions it called all succeeded.

This patch makes all the TLS tests green however there is still an error left in softhsm / rsapssam that manifests this way:

8062C5A32E7F0000:error:02000085:rsa routines:RSA_verify_PKCS1_PSS_mgf1:first octet invalid:crypto/rsa/rsa_pss.c:85:
8062C5A32E7F0000:error:1C880004:Provider routines:rsa_verify:RSA lib:providers/implementations/signature/rsa_sig.c:855:

[simo5]

Somehow the rsapssam error in softhsm appears ... once we suppress the errors we emit by pkcs11-provider itself ... I am baffled how this can be, but here we are, playing whack-a-mole ...

[simo5]

The plot thickens, if I revert the commit I added and run the whole test suite then all softhsm tests pass.
But, if after that I just run:
$ meson test -C builddir --suite softhsm rsapssam
to reproduce, the test fails.
It sounds like the bug may have always been there but simply randomly concealed, I suspect by the way memory is laid out ...

[simo5]

Unfortunately by the time I was ready to run it in gdb the error "disappeared" and now I can't easily repro it again ... now it fails like once every 10 tries, which reinforces my suspicion that there is a memory layout issue somewhere paired with some buffer overrun

[simo5]

So more and more interesting, although it is signature verification that fails it seems to be the generated signature that is bad (signature verification happens fully within openssl, only the generation happens in the token

[simo5]

Tested with valgrind but found no apparent issue, yet this time I got a different verification error:

80F21DE4C47F0000:error:02000084:rsa routines:rsa_ossl_public_decrypt:data too large for modulus:crypto/rsa/rsa_ossl.c:710:
80F21DE4C47F0000:error:1C880004:Provider routines:rsa_verify:RSA lib:providers/implementations/signature/rsa_sig.c:847:

[simo5]

The bin file is exactly 256 bytes in length, and I wonder if this is an error with 2048 bit keys which have a modulus that simply does not have enough bits in the most significant byte.
That would sound like softhsm key generation allow key generation to create keys that are not exactly 2048 bytes long but allows keys in the 2041/2047 bit length as well? ... and the test we have does require exactly that length ?

[Jakuje]

lgtm (can't approve my PR)!