build(release): vendor openssl in gravity_node so -p builds stay self-contained

[keanji-x]

Summary

• cargo build -p gravity_node (e.g. via make gravity_node) was producing a binary with dynamic libssl.so.3 + libcrypto.so.3 deps, which fail to run on hosts whose libssl ABI differs from the build host (Debian 11 vs 12, libssl1.1 vs libssl3, minor-version skew).
• Root cause: openssl-sys is pulled transitively via aptos-vault-client → native-tls, and resolver-v2 only sees the vendored feature when gravity_cli (which declares openssl = { vendored }) is part of the same cargo resolve. Scoping with -p gravity_node excludes it, so openssl-sys falls back to dynamic system linkage.
• The CI release workflow happens to build both binaries in one invocation (cargo build --bin gravity_node --bin gravity_cli) so the official artifact is fine, but make gravity_node and any one-off -p gravity_node build are brittle.
• Fix: declare openssl = { version = "0.10", features = ["vendored"] } directly on bin/gravity_node/Cargo.toml, mirroring bin/gravity_cli/Cargo.toml. openssl-sys now always builds OpenSSL from source and statically links it regardless of cargo invocation.

Verification

Build invocation	Before	After
cargo build --bin gravity_node --bin gravity_cli (CI release)	no libssl dep	no libssl dep
cargo build --bin gravity_node (no -p)	no libssl dep	no libssl dep
cargo build -p gravity_node (make gravity_node)	libssl.so.3 dynamic ❌	no libssl dep ✅

Reproduced from-scratch in rust:1.93-bookworm with apt-get remove libssl-dev libcurl4-openssl-dev first (no ssl.h in /usr/include). cargo build --profile quick-release -p gravity_node finished in 3m39s, and the resulting binary runs cleanly on debian:bookworm-slim (no libssl present) — confirms static OpenSSL 3.4.1 baked in (strings, nm, objdump -p all agree).

End-to-end node startup verified inside both debian:bookworm-slim and ubuntu:24.04 with no openssl packages installed: full reth init, RocksDB open, P2P networking up, JWT secret generated, consensus engine started, RPC HTTP/auth/IPC servers listening, plus successful outgoing HTTPS to telemetry.aptoslabs.com and sepolia.drpc.org (rustls + the vendored OpenSSL inside the binary).

After this PR, gravity_node only DT_NEEDEDs libc.so.6 / ld-linux-x86-64.so.2 / libstdc++.so.6 / libgcc_s.so.1 / libm.so.6 — all of which ship in any glibc-based base image (Debian 12 / Ubuntu 22.04+).

Follow-on commits in this PR

build(docker): drop libssl-dev / libssl3 / libudev{,1} / libzstd{,1}, add perl for vendored OpenSSL

Since gravity_node no longer DT_NEEDEDs libssl3/libudev1/libzstd1, the explicit apt installs of those packages in the runtime stage of docker/gravity_node/Dockerfile{,.host-binary} are cleaned up. Builder stage drops libssl-dev (replaced by vendored OpenSSL self-compile) and adds perl (needed by OpenSSL's Configure script).

Honesty caveat — libssl3 / libudev1 / libzstd1 are still in the runtime image as transitive dependencies of ca-certificates → openssl, dpkg / libsystemd0 / libapt-pkg6.0, and util-linux. They're structural, not removable without dropping ca-certificates (which we need for rustls cert-chain validation against external HTTPS endpoints — telemetry, drpc, GCP secret manager, etc.). This commit is about not declaring deps we don't actually consume — image content is essentially unchanged for the runtime stage.

The builder-stage libssl-dev → perl swap is a real cleanup (~few MB of dev headers gone).

build(docker): drop curl from runtime image

curl was only present for operator-side ad-hoc RPC poking (per the README); nothing in the runtime path uses it. Removing it does shrink the image — libcurl4 / libgnutls30 / libkrb5-3 / libssh2-1 / libldap-2.5-0 all come along with curl and now go away.

build(docker): switch runtime base from debian:12-slim to ubuntu:24.04

Both Dockerfile leaves switch their runtime stage from debian:12-slim to ubuntu:24.04 — longer support window (LTS to 2029 + ESM to 2034 vs Debian 12 to 2026-06 + ELTS to 2031), more glibc headroom (2.39 vs 2.36), comparable image size. Builder stage stays on rust:1.93-slim-bookworm (no upstream Ubuntu-based rust:1.93 image).

build(docker): consolidate Dockerfile.host-binary into Dockerfile as runtime-host-binary target

Restructured the main Dockerfile around two leaf targets sharing a runtime-base stage:

• runtime (default) — COPY --from=builder .... Runs cargo build inside the container. Behaviour unchanged for plain docker build .; backwards compatible.
• runtime-host-binary — COPY ${HOST_BINARY} ... from the host build context. BuildKit's stage pruning means the builder stage is genuinely skipped — no cargo runs, ~12s build vs 20-30 min from-source. If the host binary is missing the build fails fast at the COPY step.

Dockerfile.host-binary is deleted; the 4 in-repo callers — regression/pfn_chain_stress/run.sh, the matching docker-compose, and the two regression READMEs — are updated to point at the unified Dockerfile with --target runtime-host-binary.

ci(release): build + push gravity_node docker image to ghcr.io

After the native cargo build that produces the GitHub-Release binaries, the workflow now also builds a docker image via --target runtime-host-binary, then (on tag pushes only) pushes it to ghcr.io/<owner-lowercased>/gravity_node:<tag>. Stage pruning means no recompile after the native cargo step — the binary the runner just produced is the same one that ends up in the image. PR dry-runs build the image but don't push it.

• Workflow-level permissions: packages: write added so the default GITHUB_TOKEN can push to GHCR.
• Owner namespace is lowercased to satisfy GHCR's naming rules (works for any org case).
• Runner deps doc-comment updated: libssl-dev removed (no longer needed thanks to the vendored OpenSSL change), docker added.

Test plan

All verified locally:

• cargo build -p gravity_node produces a binary with no libssl / libcrypto in ldd
• cargo build --bin gravity_node --bin gravity_cli (release CI command) still works, both binaries free of libssl deps
• cargo build -p gravity_node --features randomness_disabled resolves and builds
• Built gravity_node from-scratch in a rust:1.93-bookworm container with libssl-dev removed and zero ssl.h in /usr/include — succeeded
• docker build -f docker/gravity_node/Dockerfile . (default runtime target, full multi-stage cargo build inside the container) — succeeded, 203MB image, boots cleanly with vendored-OpenSSL outbound HTTPS
• docker build --target runtime-host-binary --build-arg HOST_BINARY=... -f docker/gravity_node/Dockerfile . — succeeded in ~12s, 205MB image, boots cleanly, BuildKit confirms builder stage was pruned (no cargo build ran)
• Booted gravity_node node --dev end-to-end inside both debian:bookworm-slim and ubuntu:24.04 runtime images with no openssl packages installed
• Confirmed curl is not referenced by entrypoint.sh, docker-compose*.yaml, or any runtime path in this repo
• Verified tini lives at /usr/bin/tini and nologin at /usr/sbin/nologin on ubuntu:24.04

Will be exercised by CI on this PR (release.yml dry-run runs on PRs that touch the file, including this one):

• Self-hosted runner has docker + BuildKit available
• --target runtime-host-binary docker build step works on the runner's docker version
• (Tag-push only, not exercised by PR dry-run) GHCR login with GITHUB_TOKEN succeeds and docker push to ghcr.io/<owner>/gravity_node:<tag> works

Genuinely external — reviewer needs to confirm:

• No internal operator scripts or runbooks outside this repo rely on curl being inside the container
• No internal infra (kubernetes manifests, deploy scripts, base-image scanners) outside this repo assumes the container is Debian-derived
• No external script references the deleted docker/gravity_node/Dockerfile.host-binary (the 4 in-repo references are updated in this PR)
• ghcr.io/<owner>/gravity_node is the right image name (the workflow uses ${GITHUB_REPOSITORY_OWNER} lowercased + gravity_node; if you want a different namespace, this needs adjusting)

🤖 Generated with Claude Code