Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

asdf download cache reuse for buildkit --mount=type=cache mounts with optional keyless signing #2012

Open
yuriy-yarosh opened this issue Mar 10, 2025 · 0 comments

Comments

@yuriy-yarosh
Copy link

Is your feature request related to a problem? Please describe

It's possible to reuse architecture specific download caches via custom --mount=type=cache mounts.
I'd like to speed up asdf install in container builds by reusing mounted buildkit cache volume.

It would be nice to check hashes / sums, if any were provided by the plugin.
But ideally the whole installation process should be covered by in-toto attestation instrumentation, with further supply of provenance data on per-project basis. This way it's possible to self-sign specific plugin provided artifacts and the build process as a whole, there won't be any poisoning and binary hashes will be traceable for the whole install.

Describe the proposed solution

  1. Add a custom download dir CLI option that could be used for caching
  2. Add downloaded files hashsum and PGP certs tracking
  3. Add cosign compatibility layer for keyless signing, to approve plugin provided binaries and downloaded archives manually. Should work as a temp PGP certs replacement, if there's no hashsums or existing certs.

Describe similar asdf features and why they are not sufficient

There is some form of artifacts management and cleanups, but the actual tracking of the installation state is somewhat insufficient - it's possible to leave installs partially installed if interrupted, and there's no way to track their completeness.

It's better to start with stable caching and introduce signed reproducible builds afterwards, to omit cache poisoning. Ideally, it should follow some form of attestation and provenance e.g. in-toto slsa with keyless git signing.

Describe other workarounds you've considered

It's a security measure, if there are no hashes/certs/attestation provided - organization relying on asdf should be able to self-sign specific provenance / attestation manually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant