Add missing runtime libraries to Docker image

[fnando]

What

Install ca-certificates, libdbus-1-3, libssl3, and libudev1 in the Docker image.

Why

The image was missing runtime libraries the CLI depends on (broke on #2544), causing it to fail on startup:

$ docker run -it --rm docker.io/stellar/stellar-cli:latest --version
info: component rust-std for target wasm32v1-none is up to date
stellar: error while loading shared libraries: libdbus-1.so.3: cannot open shared object file: No such file or directory

ca-certificates is also needed for TLS to remote RPC endpoints.

Known limitations

N/A

[claude]

Claude finished @fnando's task in 1m 1s —— View job

---

Claude PR Review

• Read the Dockerfile diff
• Analyze the changes
• Check related context (entrypoint, keyring dep)
• Post review feedback

---

Summary

Small, well-targeted fix. The image was previously broken at startup because the stellar binary is dynamically linked against libdbus-1.so.3 (via the keyring crate's sync-secret-service feature — see cmd/soroban-cli/Cargo.toml:125), but that library wasn't installed. Adding libdbus-1-3 resolves the reported cannot open shared object file error. Adding ca-certificates is also correct for outbound TLS to RPC endpoints. The list is now alphabetized — nice cleanup.

Correctness

• ✅ libdbus-1-3 matches what the secret-service/keyring stack dlopens at process start. Without it the binary cannot even reach main, which matches the reproducer in the PR description.
• ✅ ca-certificates is needed for any HTTPS RPC call (reqwest/rustls and OpenSSL both look up the system trust store at /etc/ssl/certs/ca-certificates.crt). Note that the rust:latest base image does ship ca-certificates today, so this is belt-and-suspenders, but explicit is better than relying on the base image.
• ✅ libssl3 and libudev1 are retained — both still needed (OpenSSL link, and hidapi/ledger support).
• ✅ --no-install-recommends preserved, and the apt lists are still cleaned up in the same layer, so no image-size regression.

Things worth thinking about (non-blocking)

1. D-Bus daemon at runtime. Installing libdbus-1-3 lets the binary load, but there's no dbus-daemon running in the container, so any keyring-backed operation (e.g. saving a secret key to the OS keychain) will still fail — just later, with a clearer error instead of a startup crash. That's the right tradeoff for a CLI image, but it might be worth a brief note in the image docs that keychain storage is unsupported inside the container and users should use file-based identities or --secret-key env vars.

2. libsecret-1-0 not needed — confirmed. The keyring crate is configured with sync-secret-service + crypto-rust, which speaks the Secret Service D-Bus protocol directly rather than linking libsecret. So libdbus-1-3 alone is the right addition. Good call not over-installing.

3. rust:latest is a moving target. Unrelated to this PR, but the base image being rust:latest (not a pinned tag) means runtime lib versions can shift between rebuilds. If libssl3/libudev1 ever get renamed in a future Debian, this same class of breakage could recur. Worth considering pinning the base image in a follow-up.

Verdict

LGTM. The change is minimal, accurate, and directly fixes a P0 image-startup bug. I'd merge as-is.
• Branch: docker-deps

[Copilot]

Pull request overview

Adds missing runtime shared libraries to the Docker image so the stellar CLI can start successfully. Previously the image lacked libdbus-1.so.3 (pulled in via the keyring/secure-store dependency chain enabled by the default additional-libs feature) and ca-certificates (needed for TLS to HTTPS RPC endpoints).

Changes:

• Add ca-certificates and libdbus-1-3 to the runtime packages installed in the Dockerfile.
• Keep existing libssl3 and libudev1 installs; reorder alphabetically.