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.

I think this is wrong. This makes it impossible to install caroot without pulling in all of FreeBSD-runtime. My though process is 'can I use caroot without certctl' and the answer is a qualified yes - it can be done by running certctl with DESTDIR set. Conversely, 'can I use certctl without caroot' - clearly not since certctl is useless without certs. Therefor (in my mind), certctl should depend on caroot, not the other way around.

In D42095#1173152, @dfr wrote:

I think this is wrong. This makes it impossible to install caroot without pulling in all of FreeBSD-runtime. My though process is 'can I use caroot without certctl' and the answer is a qualified yes - it can be done by running certctl with DESTDIR set. Conversely, 'can I use certctl without caroot' - clearly not since certctl is useless without certs. Therefor (in my mind), certctl should depend on caroot, not the other way around.

The other way round can be defended too: your certctl with DESTDIR means certctl has use even if the host doesn’t have any certs. Maybe neither should depend on the other and there should be a meta package that is both? (Maybe with some renaming of existing packages to make it clear)

In D42095#1173183, @jrtc27 wrote:

In D42095#1173152, @dfr wrote:

I think this is wrong. This makes it impossible to install caroot without pulling in all of FreeBSD-runtime. My though process is 'can I use caroot without certctl' and the answer is a qualified yes - it can be done by running certctl with DESTDIR set. Conversely, 'can I use certctl without caroot' - clearly not since certctl is useless without certs. Therefor (in my mind), certctl should depend on caroot, not the other way around.

The other way round can be defended too: your certctl with DESTDIR means certctl has use even if the host doesn’t have any certs. Maybe neither should depend on the other and there should be a meta package that is both? (Maybe with some renaming of existing packages to make it clear)

Honestly, I think this is the best approach but in the past there has been pushback on adding pkgbase meta packages but I'm not sure I really understood why.

No, certctl is not useless without the caroot package. It can still be used to hash certificates installed from ports or some other source. On the other hand, installing caroot without the tool needed to hash the certificates it contains makes no sense.

In D42095#1173193, @des wrote:

No, certctl is not useless without the caroot package. It can still be used to hash certificates installed from ports or some other source. On the other hand, installing caroot without the tool needed to hash the certificates it contains makes no sense.

It makes perfect sense for building tiny images where certctl is only needed at build time. Installing it in the image pulls in CLI tools such as openssl and sh which are unwanted in this type of image.

In D42095#1173194, @dfr wrote:

In D42095#1173193, @des wrote:

No, certctl is not useless without the caroot package. It can still be used to hash certificates installed from ports or some other source. On the other hand, installing caroot without the tool needed to hash the certificates it contains makes no sense.

It makes perfect sense for building tiny images where certctl is only needed at build time. Installing it in the image pulls in CLI tools such as openssl and sh which are unwanted in this type of image.

Don't install caroot in the image, run certctl from outside. See D51373.

I'm pretty sure this broke the OCI image build - did you not see my comment above. I don't have time to deal with this in the near future - please either back this out or fix the image build script to use the new certctl feature.

Still waiting for your review of D51404.