How do we specify/verify checksums in package dependencies today?

Questions & Answers
1

@ryanc asked at RacketCon over the weekend (IIUC) about package server security checks, such as verifying that the downloaded artifact matches a known checksum (most package managers do this integrity verification today; different uses of the checksums and their computation are discussed by Andrew Nesbitt).

We got 2 different answers that I want to tease apart, I think

Pinning

@samth said we could provide a hash in info.rkt, which sounded to Ryan (and me) like version pinning.

I don't see how to provide a hash in info.rkt; a dependency can have a version string or a platform spec, but the version is a restricted format. (cf. package metadata). Was this a thinko, or did I miss something?

I suppose the equivalent today of pinning is to use custom catalogs, including racksnaps.defn.io.

Integrity-checking

Meanwhile, Package concepts says each package has a SHA-1 checksum which must match the package's archive (if distributed that way). But this checksum isn't given security properties by the docs (it's only used to detect changes for updating the package).

I mention this last bit because governments and security policies world-round are moving on from SHA-1 (I think the US targets 2030); I don't think this use of SHA-1 falls afoul of those ideas, since it's not a security use by my read?

Anyway, I don't read these docs as saying that even the SHA-1 checksum is used for integrity verification of downloads (despite needing to match the package's archive when distributed via archive). It also leaves out Git-distributed packages entirely, even though I think raco uses the commit ID as the checksum in those cases.

So I guess that leaves me with: do we need more integrity checks in Racket package management? Or do we already have them, and I've misread? (If so, should they move on from SHA-1?)

2

The goal I had in mind can be phrased as the question: When I install a package, how do I know that I am getting the package contents that the package author intended? Or from the perspective of a package author, how can I be sure that when a user installs one of my packages, they get the content that I intended?

The rough shape of the answer I had in mind is to allow package authors to tell the package server the cryptographic hash of the intended package contents, and for clients to check that the contents they receive match the expected hash. Details TBD. That would protect against malicious/compromised package hosts. It would not protect against malicious package authors, compromised author accounts on the package server, or compromise of the package server itself.