Feature request: Plugin checksums

[Phault]

Both wasm and toml plugins should support verifying the downloaded plugins using checksums. Right now a supply chain attack can only be mitigated for TOML plugins under specific circumstance, using the same method as described in #431.

WASM plugins, while pin-able to specific versions, can still have the assets for existing releases swapped to a malicious ones at any point.

For TOML plugins this is not solvable in a clean way before #431 is solved, however it would be possible to prompt the user to approve when the checksum changed, rather than outright rejecting it. But it wouldn't be a usable solution in CI pipelines.

I have a few ideas on how to solve it:

1) Add checksum as optional parameter to locators

^ used as separator here, but could be anything that isn't part of the URI spec. : would've been ideal, but it conflicts with urls in source:.

github:Phault/[email protected]^4b803d939a4767c38f7706506040433a6457bc64b457dfabce01678f33be0354
source:https://wherever.com/plugin.wasm^4b803d939a4767c38f7706506040433a6457bc64b457dfabce01678f33be0354

Pros: Not a big change, only 1 line that changes when a plugin is updated.
Cons: It's long and ugly.

2) Add separate [checksums] section to .prototools

dotnet = "8.0.201"

[plugins]
dotnet = "github:Phault/[email protected]"

[checksums]
dotnet = "4b803d939a4767c38f7706506040433a6457bc64b457dfabce01678f33be0354"

Pros: Simple, clean and does not mess with the plugin locator in any way.
Cons: Not obvious whether this is a checksum for the plugin or the tool itself. Could be solved with better naming maybe?

3) Add a proto.lock file

Essentially the same as 2) but moved into its own file, similar to most package managers.

Perhaps controversial due to more clutter and feels overkill for the small amount of plugins are likely to use. If however the plan is to ever have dependency-resolving for plugins, then it could make sense.

[dotnet]
sha256 = "4b803d939a4767c38f7706506040433a6457bc64b457dfabce01678f33be0354"
# extra data?

---

In any case using proto plugin add should be the recommended way to add plugins, so that checksums can be automatically added if missing. Additionally proto use could add missing checksums, but that also requires keeping track of which .prototools the plugins entry came from.

Personally prefer 2. and like 3. the least.

[milesj]

Yeah checksums are on the roadmap in some capacity. It's why https://github.com/moonrepo/build-wasm-plugin already generates .sha256 files. TOML plugins are... very tricky though.

Checksums shouldn't be configurable at all by the users, as that goes against how checksums work. If anything, it would probably be a lock file somewhere, but I need to look into it a bit more.

A lot of these problems would go away also if we had a central registry somewhere.

[Phault]

Yeah preferably the checksums should be semi-hidden from the user, so they don't assume they need to mess with it manually. I guess that's the best argument for going with the lockfile approach, even if it is a bunch more work, and an extra file to keep track of.

I've been toying with the idea of a community registry, and it's actually the whole reason why I've been thinking of pinning, checksumming and custom locators. With the former two, someone could set up something semi-trustable like similar to https://plugins.dprint.dev, either using the same Github-based approach, or backed by a vetted repo like https://github.com/JuliaRegistries/General/.

Got something running at https://proto-plugins.deno.dev/act.toml and https://proto-plugins.deno.dev/[email protected] like this, but I don't like that people have to trust that the files aren't suddenly swapped either in a malicious or just breaking way (for toml plugins).

[milesj]

Yeah agreed. My current top choice for a "registry" is Axo releases: https://blog.axo.dev/2024/01/axo-releases-urls

But it's relatively new, and I need to audit how it works to see if it's viable.

[z0rrn]

1. I actually like the second approach because it nicely separates the checksum and download file but keeps them in the same file.
   One of the reasons why I use Proto is that it only uses one file. I want to keep my project root clean and simple (if you introduce a lockfile maybe let Proto automatically search for both files in a .proto directory and add a flag to create the lockfile there at first invocation).
2. I think a registry should be entirely optional. The possibility to easily verify a Plugin because it's just one TOML file, not multiple Bash/Lua files, should also be preserved.

[milesj]

I think when we do a lockfile, it would be a global lockfile at like ~/.proto/tools.lock or something, since it needs to track all the proto install tools.

[z0rrn]

If it's only global I like the idea.

[varshith257]

@milesj Is this feature to be implemented or had any roadblocks ,?

[milesj]

It's blocked until we have a plugin registry.