This seems like the right dep order to me

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.