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: 8b4015b

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.