Skip to content

Digest utilities for the embedded runtime (SHA-256) (P2) #99

Description

@turinglambdaai

Found while auditing PodLens (turinglambdaai/podlens).

Problem

The update contract (docs/UPDATE.md pattern shared across Rivet apps) requires SHA-256 over release artifacts, but the embedded Racket runtime does not stage third-party packages, so crypto is unavailable and the Racket distribution itself has no usable SHA-256 collect. PodLens ended up vendoring a ~85-line pure-Racket FIPS 180-4 implementation inside app/core/util.rkt (with its own test vectors) purely to keep that door open — it is dead weight in the app today because the native hosts do the artifact hashing.

Any Rivet app that wants its Racket/CLI side to verify a downloaded update artifact against the signed manifest will have to vendor the same code.

Proposal

Ship digest utilities in Rivet proper — e.g. rivet/digest providing sha256 (bytes → bytes) — either as a pure-Racket implementation (PodLens's can be donated, it is verified against FIPS 180-4 vectors including the one-million-'a' case) or via whatever primitive the embedded runtime exposes. With tests in the Rivet tree, apps can then (require rivet/digest) instead of each maintaining a private crypto file.

PodLens side: the vendored copy was deleted in the same audit that produced this issue; if/when the Racket side needs to verify artifacts, rivet/digest is the shape it should come in.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions