Comment 6 for bug 1905790

Soo... Given we prefer to stay conservative and not change SSSD crypto backend fully (to be clear, I would have preferred it to follow upstream, not to provide a solution that will change in next LTS no matter what, and avoid having "frankensteins", but wasn't a strong requirement for me) I've been exploring ways to get only the component we care (p11_child) to use p11-kit and openssl.

As per this, I've prepared two possible approaches in two patches (I'd just squash those or pick one in case).

The simplest approach [1] was to just compile the NSS version and then only the p11_child using OpenSSL and then manually install to the package... Ensuring that we always pass to it a PEM CA cert file. Works, but will not allow us to test it using upstream tests.

So, I've added a further patch that acts mostly on upstream code and removes the usage of libnss ONLY from p11_child and its related operations (smartcard and ssh auth), you can see it better in this patch-queue branch (check the default one to see the debian/* changes):
 - https://salsa.debian.org/3v1n0-guest/sssd/-/commits/patch-queue/p11-kit-p11_child

This works properly and it's tested, you can try the packages at:
 - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4361.1

Theoretically, it would be even possible to keep support for an NSS p11_child (i.e. provide two binaries, and select which one to use depending on the db defined in configuration file), but as said in the bug description I don't think that such change would actually matter for anyone, as we don't provide a system NSS database.

Robie, this would be better SRU approach?

[1] https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child-v1