Add dependency auto-installation support for certain Linux platforms

[lmco-dvinci]

Name of feature: Linux dependency auto-installation

Pain or issue this feature alleviates:

#20

Is there documentation on how to use this feature? If so, where?

Unfortunately not. If you can point me where docs should go (if not just in the README), I'll gladly write them. It uses two environment variables: TRUSTSTORE_INSTALL_CA_PACKAGE and TRUSTSTORE_IGNORE_PACKAGE_CERTS. If set to true, the former attempts to install the needed packages for CA installation from the distro package manager, and the latter will do that while ignoring upstream cert validity. This is useful when you're behind corporate SSL inspection, which is my use-case.

In what environments or workflows is this feature supported?

This works for Debian-likes and Alpine.

In what environments or workflows is this feature explicitly NOT supported (if any)?

Anything that isn't a Linux distro. I should note that RHEL and its derivatives do not appear to need this, as they've ensured relevant packages are always available, even on minimal installs.

Supporting links/other PRs/issues:

#20

---

Please let me know if any clean-up needs to be done.

Changes I've made to the code:

• what used to be done in init() is now done in another function, setCommandAndFileVariables(), so they can be set again after attempting to install relevant packages
• there are now variables for TRUSTSTORE_INSTALL_CA_PACKAGE and TRUSTSTORE_IGNORE_PACKAGE_CERTS
• added an existsOnPath() function that returns true when a binary is on path, false when not - this is useful for package manager resolution, and also cleans up setCommandAndFileVariables() a bit
• installPlatform() and uninstallPlatform() now hit tryDetermineOsAndInstall(), a function that tries to install relevant packages if TRUSTSTORE_INSTALL_CA_PACKAGE is true

I've tested this internally with a pipeline that runs a binary using this library on these distros:

• Alpine 3.17
• Alpine 3.18
• Debian 12 (bookworm)
• RHEL UBI9 Minimal
• RHEL 9

The test downloaded a copy of my employer's CA certs, then tried to install them using this library. After that, it tried to verify an SSL connection that uses those certs. Permutations were added for the values of TRUSTSTORE_INSTALL_CA_PACKAGE and TRUSTSTORE_IGNORE_PACKAGE_CERTS.

Closes #20.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[lmco-dvinci]

Please review regardless of the CLA - will see what legal thinks of it..

[maraino]

Hi, I've been looking again at what mkcert is doing. I'd like to match as much as possible their behavior. In their code, they don't have anything for installing tools to manage the system truststore, but they have for managing the NSS truststore (firefox-based tools).

See truststore_linux.go#L28-L35. Depending on the package manager, they suggest installing certutil showing the command, instead of automatically executing it.

We probably should also add a SystemTrustCommandHelp that shows the command to run. Then that command can be displayed on the truststore binary or step.

Can you change your PR with something like that? What about adding dnf or yum, and apparently zypper (I didn't know about this one).

[lmco-dvinci]

My use-case is automatically executing this to add my employer's CA to container images. I've ignored dnf/yum as RHEL and friends appear to include the needed utilities in even their minimal images. I'll add zypper if this PR is still desired - I ignored it, as I'm not even aware of any images that use SUSE as a base, and searching my employer's internal container registry didn't yield anything.

[maraino]

My use-case is automatically executing this to add my employer's CA to container images. I've ignored dnf/yum as RHEL and friends appear to include the needed utilities in even their minimal images. I'll add zypper if this PR is still desired - I ignored it, as I'm not even aware of any images that use SUSE as a base, and searching my employer's internal container registry didn't yield anything.

Automatically executing this using a tool you have developed? Using cmd/trustore? Using step-cli?

[lmco-dvinci]

Using a tool we've developed.

[maraino]

Using a tool we've developed.

In that case I think it's better to get the dependencies from truststore, the command too, like truststore_linux.go#L28-L35, and you can call it from your tool. We don't want our tools to install any extra package automatically.