My goal with the previous change (hash 1d7ffb3) was to be able to install the caroot files in an empty chroot. This can be used as a base container image for statically linked SSL workloads. The other change in that commit to separate out openssl libs allows for a similar (but slightly larger) base image for dynamically linked SSL workloads. When building these images, I use the build host's certctl with DESTDIR set to generate the contents of $chroot/etc/ssl.

Making caroot depend on certctl would pull in the whole of the runtime package which is not wanted for these use-cases. I particularly want to avoid installing base utilities and /bin/sh along with their libraries - its a waste of space and expands the attack surface within the container.

In D42095#960934, @dfr wrote:

My goal with the previous change (hash 1d7ffb3) was to be able to install the caroot files in an empty chroot. This can be used as a base container image for statically linked SSL workloads.

You'd still need to hash them. So a better solution is to modify certctl to copy instead of symlinking, and just run certctl -D /path/to/jail without installing anything.

In D42095#960999, @des wrote:

In D42095#960934, @dfr wrote:

My goal with the previous change (hash 1d7ffb3) was to be able to install the caroot files in an empty chroot. This can be used as a base container image for statically linked SSL workloads.

You'd still need to hash them. So a better solution is to modify certctl to copy instead of symlinking, and just run certctl -D /path/to/jail without installing anything.

I don't want to install the build host's certs - I want the ones from the caroot package that my build system spits out for the freebsd version that matches the version I want for the container image.

I'm guessing that your goal is to be able to install certctl without caroot from base and then hash data from somewhere else (e.g. security/ca_root_nss). If so, we could both get what we want if the certs move to a new package, e.g. caroot-data and then caroot can just depend on both caroot-data and certctl. I can install caroot-data into my tiny images and you can install certctl without caroot-data. Would that work?

In D42095#961004, @dfr wrote:

In D42095#960999, @des wrote:

In D42095#960934, @dfr wrote:

My goal with the previous change (hash 1d7ffb3) was to be able to install the caroot files in an empty chroot. This can be used as a base container image for statically linked SSL workloads.

You'd still need to hash them. So a better solution is to modify certctl to copy instead of symlinking, and just run certctl -D /path/to/jail without installing anything.

I don't want to install the build host's certs - I want the ones from the caroot package that my build system spits out for the freebsd version that matches the version I want for the container image.

I'm guessing that your goal is to be able to install certctl without caroot from base and then hash data from somewhere else (e.g. security/ca_root_nss). If so, we could both get what we want if the certs move to a new package, e.g. caroot-data and then caroot can just depend on both caroot-data and certctl. I can install caroot-data into my tiny images and you can install certctl without caroot-data. Would that work?

I'm lost, what would caroot contain then ?

I'm lost, what would caroot contain then ?

Probably just the install scripts that rehash the data? It starts to look like a metapackage which I know you don't like. Do you have any other suggestions on a way forward? I really don't want to back out my previous change to split caroot and certctl apart

Perhaps just remove the dependency from caroot to certctl entirely?

In D42095#961023, @dfr wrote:

I'm lost, what would caroot contain then ?

Probably just the install scripts that rehash the data? It starts to look like a metapackage which I know you don't like. Do you have any other suggestions on a way forward? I really don't want to back out my previous change to split caroot and certctl apart

The script is in certctl right now, having an empty meta-package just for a post-install script seems a bad design to me.

Perhaps just remove the dependency from caroot to certctl entirely?

That's what I was asking myself earlier but the problem with this approch is that if you pkg install FreeBSD-\* (or something like that) nothing guaranty that caroot will be installed before certctl and you have a non fonctional installation because certctl wasn't run.

Perhaps just remove the dependency from caroot to certctl entirely?

That's what I was asking myself earlier but the problem with this approch is that if you pkg install FreeBSD-\* (or something like that) nothing guaranty that caroot will be installed before certctl and you have a non fonctional installation because certctl wasn't run.

Yes, that would be a problem. I can't currently think of a way around that without the caroot 'metapackage'. I don't really think of it in the same way as a kind of 'package group' metapackage - in this case it serves a specific function to get the right ordering of package installs and initialisations.

It's too bad we can't have a shared pkg-install that will just run certctl once when either caroot or certctl (or both) are updated, the former only if there's an executable certctl in $PATH.

guest-patmaddox added a subscriber: guest-patmaddox.Dec 13 2023, 9:57 PM