Opt-out for copying /etc/pki/ca-trust/source into the root?

[reubeno]

Are there any supported methods of requesting mock skip copying /etc/pki-ca-trust/source (and /usr/share/pki/ca-trust-source) into the root environment? I'm expecting the answer to be "no" based on my read of the code, so my immediate follow-up question would be: are you open to a contribution to add a new config option to allow opting out of the copy?

(I see that copy_certs() unconditionally copies these directories into the root, and this is invoked in each call to _PackageManager.initialize(). I do see precedent for some configuration in this area, via ssl_ca_bundle_path and ssl_extra_certs config options that can be configured via .cfg file.)

As context -- I'm running into errors building certain packages with mock on an Azure Linux 3.0 host system. (As an aside, I work on the Azure Linux project and it's been great to see the recently added support for Azure Linux! I'd love to figure out how to contribute toward that support in the future.) On Azure Linux 3.0, the ca-certificates-shared package (depended on by ca-certificates) installs a symlink under /etc/pki/ca-trust/source ("blocklist")--and a similar one under /usr/share/pki/ca-trust-source. When mock creates and initializes an Azure Linux 3.0-based root, this package doesn't need to be installed into the root, but copy_certs() will copy in these dirs. During the copy operation, the (dir) symlink turns into a non-symlink directory in the root. When a package build ends up requiring ca-certificates (and thus ca-certificates-shared) to be installed into the root, the install transaction fails with a cpio error because the copied directory conflicts with dnf trying to install a symlink.

I've spoken with maintainers of the ca-certificates-shared package in Azure Linux 3.0, and there's agreement to remove the symlink for the next major release of the distro, but it looks like we'll need to live with it for 3.0.

More broadly, I can see an argument for a build scenario in which the root is either disconnected from the network (and doesn't need these certs), or network-enabled but wants to be more "narrowly trusting" than the host system. In these cases, I could see general value for such a policy option to allow a caller to disable this copying functionality.

Either way, I appreciate any help / pointers / feedback in advance. If there is openness to a new config option, I'm happy to draft a PR and work on the contribution. If there are concerns about the idea of adding such an option, it would be great for any pointers on alternative options for avoiding the specific challenges we're running into.

Thanks!

[praiskup]

Thank you for the question and welcome! Awesome to see we are having another potential Azure Linux config contributor/maintainer!

Are there any supported methods of requesting mock skip copying /etc/pki-ca-trust/source (and /usr/share/pki/ca-trust-source) into the root environment?

Can you try to set the mentioned options, ie. ssl_ca_bundle_path and ssl_extra_certs to None (not a string, but Python None literal)?

are you open to a contribution

Sure! If the above doesn't help, we can have a new option. Please keep the default behavior withouth changes, and document the new options you add.

[praiskup]

I tried setting ssl_ca_bundle_path and ssl_extra_certs to None but hit the same issue

That is weird, see this and this conditions. The logic is skipped if set to None. Then finally, there's this condition that should imply that nothing is copied into the buildroot (just into the bootstrap chroot).

I must be missing something.

[praiskup]

Hm it seems bootstrap is disabled which means that DNF actually uses SSL configuration from host. Might be related.

[reubeno]

This appears to be the challenge. I also noticed the conditional checks around the bundle and extra-cert copying, but don't see any guarding the copy of the files I list above.

Or perhaps I'm missing something?

[reubeno]

@praiskup -- thanks for the discussion thus far. I've posted a draft PR: #1573 pursuing the 3rd option above. It would be great to get input on the approach as well as any other testing I should be doing to ensure there will be no impact on the default configurations.

[praiskup]

Nice catch! Thank you for the PR.