Release HSM builds

[p3lim]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

You already release HSM builds for container runtimes, but it'd be nice if these versions were also released for DEB/RPM. It could follow the same naming scheme by suffixing "-hsm" to the name, and in both DEB and RPM you could set it to be exclusive with the normal package (and the other way around).

Sidenote: it would be nice if the systemd unit file was included in the DEB and RPM files (under /usr/lib/systemd/system/), including a system user (step). This is most likely the way everyone use the releases on those systems. Users could easily just use systemctl edit, or write their own (in /etc/systemd/system) if they need to make adjustments, but the one you provide should be the default.

Why is this needed?

Installing a bunch of libraries, a whole language (which would have to match with the version you've coded it with), downloading the source and then compiling (or even cross-compiling) is quite painful, especially on low-powered devices where one would want to run signing in smaller environments. Also, when building like this, keeping it up-to-date is just as cumbersome. It's quite common (from my experience) to use step-ca with some kind of KSM, which makes me question why this isn't in the release by default.

While I could just use the container image for this, it's not always as easy to set up and run Docker on some devices (resource exhaustion is a real problem), just pulling the image is enough to OOM sometimes.

[hslatman]

Hey @p3lim, historically we've decided to not create these builds to limit the number of builds that we need to maintain, for roughly the same reasons you're describing in the issue. Generally those builds will require CGO, and that will make our lives quite a bit harder when trying to support different Linux versions and such, as we'd need to test these additional systems too (the Docker ones are simpler; as there are less moving parts). We'd also need to overhaul our current GoReleaser config, and it would incur additional time in our CI runners. It would be great if we had the time and resources to support those, but the current reality is that we can't support those builds properly atm, so for now I'll close this issue.

[p3lim]

@hslatman What if the HSM capability was offloaded to a plugin? This is something you've already got a system in place for. That way the "core" could stay as it is, nice and portable, and then the plugins can be a mess but contained. HSM support is already partially delegated to a plugin anyways (atleast for the CLI), but the server component could just as well be. This would also allow better integration with step ca init supporting other HSM/KSM backends (which sadly only supports azure right now).

[hailfinger]

@hslatman having two builds for each configuration sounds quite painful. Would a single deb build with cgo for latest Debian on arm64+amd64 be acceptable?
As an alternative, having a build recipe to build a .deb with HSM support would be a very workable way to prevent additional CI resource requirements. People in need of a .deb could then build it themselves.