OpenSCAP
Fix broken build with NSS crypto back end
This PR will help us investigate possible alternatives to using GCrypt library in our project.
OpenSCAP had 2 alternatives of crypto libraries, GCrypt and NSS. GCrypt is the default back end.
We discovered that building with the NSS back end is broken at this moment.
This patch fixes the broken build. Then, it adds missing parts of code for the NSS implementation. Finally, it consolidates the duplicate code and simplifies the code. This simplification will make future changes easier, which will also help us with the investigation.
Use cmake -DWITH_CRYPTO=nss .. to configure with NSS. The crypto features are covered by tests probes/filehash58/test_probes_filehash58.sh and API/crypt/test_api_crypt.sh.
Related to: https://issues.redhat.com/browse/RHEL-22013
I have rebased this PR on the top of the latest upstream maint-1.3 branch.
Okay, so how about you'll also change the default GCrypt to NSS in this PR to run our CI with it (packit included)? Later we can contain it to Fedoras (just like we did with PCRE2) before merging (or just Rawhide, maybe, given we merge it at all, but we must be sure it is not broken anyway before making this descision).
@evgenyz Now it builds and tests on Linux, but not on OS X and Windows. What to do next?
We can pause for now. There is a decision to be made: use NSS everywhere and potentially drop GCrypt at some point or switch to OpenSSL.
I you have any insights that can sway this decision in any direction update the ticket.
OK. Let's keep this open until we investigate and decide.
But regarding dropping the Gcrypt, I think we can't drop it from upstream and I also think that we shouldn't change the default crypto library in the maint-1.3 branch. I think doing these things would break the compatibility of the maint-1.3 branch with 1.3.0 release that we keep there. I think that upstream we can only extend the CI and update the spec, but we shouldn't change the defaults in maint-1.3.
You're correct about defaults, but there is a nuance: we need either OpenSSL or NSS to be the bakend-in-use for openscap-1.3 in Fedora ELN at least. Probably it makes sense to do that for Rawhide or all Fedoras (in our upstream spec).
Okay, so where we are going to gate this backend? Fedora in GH Actions? Fedoras in Packit? All Fedoras? New F Rawhide GH Action?
@evgenyz I think the easiest way would be to create a new job in GitHub actions using Fedora. Would you prefer to have that in this PR or in a separate PR.
@evgenyz I think the easiest way would be to create a new job in GitHub actions using Fedora. Would you prefer to have that in this PR or in a separate PR.
I don't mind it being a separate PR. Just link it here for posterity.