Extend no-rustls test

[Jakob-Naucke]

We test that rustls isn't used:

operator/.github/workflows/lint.yml

Line 58 in f652cc0

- name: "Ensure rustls isn't used"

but for easier downstreaming, we want to make sure we're align with https://gitlab.com/redhat-crypto/fedora-crypto-policies at all times.

The Fedora Crypto Policies are an allowlist of backends. However, only a blocklist is easy to implement:

• One approach is to add popular crates to the blocklist based on https://crates.io/keywords/crypto and https://crates.io/categories/cryptography. One crate that we identified in operator: KBS API for LUKS key registration #248 with unclear Fedora alignment is aws-lc-rs.
• A more sophisticated approach would be checking if a crate falls under the categories of the bullet above (keyword "crypto" or category "cryptography") and blocking all those except allowed ones (like openssl)

If more logic is needed, the test could be expanded into a test written in Rust.

[SpaceFace02]

Could you please add a brief description to this issue too?

[Jakob-Naucke]

Updated!

[SpaceFace02]

Just wanted to confirm a few things
We are setting oci-client feature to native tls here.

And oci-client also bundles in jsonwebtoken/rust_crypto(which brings a whole load of transitive dependencies along), which also has unclear Fedora alignment, similar to aws_lc_rs. (link)

So both directions are equally problematic,

Btw, I was trying to go with the second approach of blocklisting all and allowlisting only specified ones (similar to a firewall), but not sure what packages can be added to the whitelist

[SpaceFace02]

Do we have a issue raised for allowing use of this crate for oci-client as discussed in this PR?

[Jakob-Naucke]

And oci-client also bundles in jsonwebtoken/rust_crypto(which brings a whole load of transitive dependencies along), which also has unclear Fedora alignment, similar to aws_lc_rs. (link)

Good find; ideally, oci-client with native-tls should use jsonwebtoken-openssl (which is very new so it's unsurprising they aren't using it yet)

Btw, I was trying to go with the second approach of blocklisting all and allowlisting only specified ones (similar to a firewall), but not sure what packages can be added to the whitelist

I'd say if you go with the approach of checking crates.io for the keyword "crypto" or category "cryptography", and then allowed all the ones that we currently use, we could just discuss based on the PR if any of those misalign with the policy

Do we have a issue raised for allowing use of this crate for oci-client as discussed in this PR?

We should allow it when resolving #301 (this issue) but I don't see why we'd need an extra issue for it?

[SpaceFace02]

We should allow it when resolving #301 (this issue) but I don't see why we'd need an extra issue for it?

I meant creating a feature request for enabling jsonwebtoken-openssl on oci-client (here) if we have native-tls feature selected (link), but you already answered the question more or less here :)

which is very new so it's unsurprising they aren't using it yet

I'd say if you go with the approach of checking crates.io for the keyword "crypto" or category "cryptography", and then allowed all the ones that we currently use, we could just discuss based on the PR if any of those misalign with the policy

Yeah, the approach I am working on is creating a custom test and running this test as part of the GHA pipeline.