systemd-cryptsetup dependency chain

[mikn]

Description of changes:
This introduces a chain of dependencies for enabling systemd-cryptsetup. Initially, I did not compile the cryptsetup binary itself and I did not package the systemd-cryptenroll binary as we would embed them in our admin container and in our bootstrap system, but I guess it would be more useful to have them part of the primary system? Willing to discuss though.

I am also unsure whether the devmapper-event library is needed or not.

Testing done:
I have made sure the binaries don't give linking errors when invoked, but I have not tested primary functionality yet. Will happen later.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[mikn]

I am currently maintaining this in our variant repository as well, but would appreciate to get this upstream as discussed.

[cbgbt]

Thanks for your contribution, and apologies for the latency -- things are a bit slow on account of the holidays. We'll have a look!

[mikn]

That's okay! I have some patches to push to this after the holidays. There is an optional dependency on libargon2 also in cryptsetup which is not yet included. IT is a key derivation algorthim which has not yet been fips certified however. We want to use it ourselves as we have no fips requirements as such and it is a provably more secure key derivation algorithm than the pbkdf2 algo which is fips approved.
I would need some help to allow the FIPS switch to work in this dependency chain.

[bcressey]

Back from vacation now and taking a look!

Are you OK if I push minor fix commits to your branch for this PR? Not sure if you enabled that flag but it could save some round trips for cleanup stuff that might otherwise annoy you.

[bcressey]

Ideally this package would be named libcrypto since it provides that shared library.

[mikn]

I did name it this as we are also building libssl as per the comment below. I think for us, we do want libssl if possible, as we will probably set up remote systemd-journal with TLS soonish also (for audit logging).
We could split up the install packages though?

[bcressey]

If nothing needs libssl.so, only libcrypto.so, I'd prefer to disable it to cut down on surface area for potential vulnerabilities:

Suggested change

	-DBUILD_SHARED_LIBS=ON \
	-DBUILD_SHARED_LIBS=ON \
	-DBUILD_LIBSSL=OFF \

[mikn]

Okay, I tried building now and it does activate a fair few things in systemd (to have openssl available) - I spotted that udev did not build, neither did the shared library.
I do not really have time to dive into this and craft a patch to only enable the crypto dependencies in Systemd (and not the libssl ones), but I do apologise for polluting your otherwise very pristine distro with libssl. 🥲

[mikn]

Firstly, thank you for the review!

Back from vacation now and taking a look!

Are you OK if I push minor fix commits to your branch for this PR? Not sure if you enabled that flag but it could save some round trips for cleanup stuff that might otherwise annoy you.

I actually don't know how to enable that! But you are welcome to!

wrt disabling building libssl.so I think that is a bit hairy, as systemd, with the -Dopenssl=true enables a few other things (such as DNSSEC, and thus SSL, in resolved). It is however required to pass in to enable tpm2 support.

I am unsure whether tss2 requires libssl or just libcrypto. I can try to see where things break, but it will probably be next week as we are in the middle of delivery this week.

[mikn]

Okay - as mentioned in previous comments, we would prefer if libssl also ends up in Bottlerocket together with libcrypto despite how much effort you spent avoiding that very fact. 🥹
I think it is up to you @bcressey and/or the rest of the team at AWS if this is something you would like to support or not.

For clarity; we would probably not spend the time to craft out the patch required soon to not enable libssl dependencies in systemd ourselves, as we most likely would need it down the road for securing our audit log system. (Currently the design is using remote systemd-journald as it is one of the very few integrated log storage, filtering and forwarding solutions)

Let me know how we should move forward. 🙏