Use docker hardened images

[endersonmaia]

This pull request updates the SDK's Docker build process and related configuration to improve image security and flexibility. The main changes include switching to hardened base images from a private registry, splitting PostgreSQL images into build and runtime variants, and refining the Dockerfile to streamline dependencies and user creation.

Container base image and registry updates:

• Switched the default Debian base image from Docker Hub to a hardened image hosted on dhi.io for improved security (packages/sdk/docker-bake.hcl).
• Added a new GitHub Actions workflow step to log in to the Docker Hardened Registry (dhi.io) before building images (.github/workflows/sdk.yaml).

PostgreSQL image improvements:

• Split the PostgreSQL base image into separate build and runtime images, using the official image for building and a hardened runtime image from dhi.io for production, with configurable major version support (packages/sdk/docker-bake.hcl, packages/sdk/Dockerfile). [1] [2] [3]
• Updated the data directory copy step to set correct ownership and permissions, and to use the major version in the path, aligning with best practices for PostgreSQL containers (packages/sdk/Dockerfile).

Dockerfile dependency and user management:

• Refined the Dockerfile to install only necessary packages for user creation (passwd), then remove them immediately after use to reduce image size and attack surface (packages/sdk/Dockerfile). [1] [2]
• Cleaned up unnecessary packages in the final image, removing lua5.4 and xz-utils from the runtime dependencies (packages/sdk/Dockerfile).

Build process enhancements:

• Ensured the /usr/local/bin directory exists before extracting binaries, improving reliability during the build (packages/sdk/Dockerfile).
• Changed the way the forge binary is included, copying it from a prior build stage instead of downloading it again, which improves build caching and consistency (packages/sdk/Dockerfile).

[changeset-bot]

⚠️ No Changeset found

Latest commit: 5962012

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[brunomenezes]

For me would be a solid yes. @endersonmaia there is some rebase to be done.

cc: @tuler do you have any comments related to the change?

[endersonmaia]

On extra thing I did in the PR was to enable the trivy image scan for CVEs in the images built by the sdk package.

The cartesi/sdk is failing because it has javascript projects inside that have CRITICAL/HIGH CVEs.

We need to decide how to handle this.

[brunomenezes]

On extra thing I did in the PR was to enable the trivy image scan for CVEs in the images built by the sdk package.

The cartesi/sdk is failing because it has javascript projects inside that have CRITICAL/HIGH CVEs.

We need to decide how to handle this.

By running bun audit, I got back 18 vulnerabilities (10 high, 5 moderate, 3 low), but it needs to be checked case by case because, for example the rollup that is used by tsup is marked ashigh, however it is only for codegen/build, not exposed to users. Nevertheless, it ought to be addressed: what I mean is whether it is high or low in such cases.

[endersonmaia]

On extra thing I did in the PR was to enable the trivy image scan for CVEs in the images built by the sdk package.
The cartesi/sdk is failing because it has javascript projects inside that have CRITICAL/HIGH CVEs.
We need to decide how to handle this.

By running bun audit, I got back 18 vulnerabilities (10 high, 5 moderate, 3 low), but it needs to be checked case by case because, for example the rollup that is used by tsup is marked ashigh, however it is only for codegen/build, not exposed to users. Nevertheless, it ought to be addressed: what I mean is whether it is high or low in such cases.

The CVEs that this PR gets, is from the container images built in packages/sdk.

So inside the cartesi/sdk image, there's nodejs build process at https://github.com/cartesi/cli/blob/feature/use-docker-hardened-images/packages/sdk/Dockerfile#L236-L239

I think bun audit will only check for packages.json it can find in this monorepo, which is useful, but task for another issue/PR.

[brunomenezes]

The CVEs that this PR gets, is from the container images built in packages/sdk.

So inside the cartesi/sdk image, there's nodejs build process at https://github.com/cartesi/cli/blob/feature/use-docker-hardened-images/packages/sdk/Dockerfile#L236-L239

I think bun audit will only check for packages.json it can find in this monorepo, which is useful, but task for another issue/PR.

You're right, it only checks our own monorepo. I run that because the failed build does not say much besides the return code 1. I could not see any report attachments or links to some result. Did I miss something?

So you're saying that the problem is in building a third-party alto that serves as the ERC-4337 bundler. In the bake file, the tag version used to checkout Alto is v1.2.5. It looks like they have newer patch versions [1.2.6, 1.2.7], but they are unlikely to contain dependency upgrades. Maybe it's worth a try to bump and start the build.

Another thing I briefly discussed with @tuler is replacing Alto with Rundler from Alchemy (repo link), since he thinks it is better maintained.

PS: Also, something to think about when we're moving to a stricter rule (i.e., using DHI) is that, since we use a lot of third parties we don't control, and if we can't loosen up a bit in certain situations, it may often become a blocker.

[endersonmaia]

I could not see any report attachments or links to some result. Did I miss something?

They're on the Action Summary https://github.com/cartesi/cli/actions/runs/22623090609/attempts/1#summary-65555014961

Maybe it's worth a try to bump and start the build.

I'll send a fixup with this bump.

replacing Alto with Rundler

I'll need help with that, since I don't know how to use/exercise the features provided by Alto/Rundler.

if we can't loosen up a bit in certain situations, it may often become a blocker.

We have the power to rebase/merge anyway, after an approval. The CI job will make its job of alerting us.

[brunomenezes]

They're on the Action Summary https://github.com/cartesi/cli/actions/runs/22623090609/attempts/1#summary-65555014961

Thanks for pointing that out.

I'll need help with that, since I don't know how to use/exercise the features provided by Alto/Rundler.

I am not saying to do that here. Just highlighting a conversation where an assessment was suggested in terms of if features we use on one match the other is more about which one has better maintenance. Also, I myself need to be acquainted with this piece and other parts of the CLI project.

We have the power to rebase/merge anyway, after an approval. The CI job will make its job of alerting us.

Gotcha! It is more of an alert than a PR blocker, per se.

[endersonmaia]

Did the alto bump on another PR #437