Integrity checks for downloaded linters

[siddharthab]

Can we include some integrity checks for the linters configured in this repo?

The schema for trunk.yaml allows a shasum attribute, but the problem is that the URLs are parametrized by version for most linters configured in this repo, and so there is no one fixed shasum. Instead, we could have a central map/registry of all known download URLs to their shasums, and then if a user is using a download URL with an unavailable shasum, warn them and show them how to extend the shasum registry for their repo.

Filing it here for consideration. Apologies if this already happens in some way.

[sxlijin]

Thanks for the suggestion! Would you say your concern is motivated by a desire to provide resilience against mid-download bitflips (e.g. lost packets, a bad NIC), security (e.g. a malicious release of a given linter), or something else?

There are two things we currently do to assert that a download is well-formed (neither of which are meant to provide security assurances - that's a bigger can of worms that we're not yet positioned to address):

• many linters come with a version_command field (c.f. black), which when we encounter a linter failure, we use as a health check for the linter itself; if the health check fails, we invalidate the linter download and will re-download on the next invocation
• trunk upgrade only upgrades linters to versions that have passed the integration tests we define in this repo; this guarantee is provided by a service that we operate

[siddharthab]

Thank you for the additional information. I would say our concern is incomplete/incorrect downloads for reasons malicious or benign. So mostly it's some security assurances, but not all.

We can not really do anything against a malicious release of a linter, other than building the binary from source ourselves after reviewing the source code. For that, we rely on using only well-known linters, hoping that any problem there will be discovered soon.

[siddharthab]

If the Linter Upgrade Validation process is already recording the validation status of a linter version, maybe it can also record the shasum of the downloaded linter.

[sxlijin]

Got it - so you primarily want some kind of attestation claim, i.e. something that provides a stronger guarantee than a version specifier.

I'll go ahead and add this to our FR tracker.

[siddharthab]

Thank you! Not any kind of urgency to it, just thought I should put down my thoughts.