provisioning dprint plugins in restricted environments

[Adrian]

Thinks thank you fro this amazing project.

I'm in a highly restrictive environment where every artefact downloaded from the internet needs to be vetted first and is then locked with a hash so that if it needs to ever be re-downloaded, it's hash is checked against a databases of vetted hashes (containing a mapping url => hash) and rejected if it doesn't match.

I am not able to use dprint plugins in this environment since dprint plugins are downloaded by dprint itself and then transformed in a way which is not immediately obvious (and which also seem non-reproducible).

My first attempt was to download the plugins myself (verifying the hashes) and place them in dprint cache dir for dprint to find. I managed do that (including creation of plugin-cache-manifest.json) so that dprint no longer attempts to download the plugins, however I get the following error at runtime:

Error resolving plugin https://plugins.dprint.dev/json-0.17.0.wasm: Error deserializing compiled wasm module: incompatible binary: The provided bytes are not wasmer-universal

this is with https://plugins.dprint.dev/json-0.17.4.wasm downloaded and placed at $DPRINT_CACHE_DIR/plugins/dprint-plugin-json/0.17.0-4.0.0-x86_64

When I let dprint download the plugin, the size of the above file differs (3545040 vs 2215703 bytes) so I gather that dprint applies some transformation to the downloaded file (decompression?). However this transformation seems to be non-reproducible (it yields file with different hash on different linux machines).

Is there a way of making this transformation deterministic? Or could I apply it to the downloaded file myself (with some of-the-shelf CLI tool) so that dprint can simply consume the file it finds in the cache dir?

Thanks for your help!

[Adrian]

However this transformation seems to be non-reproducible (it yields file with different hash on different linux machines).

Note that in both cases I run dprint in a sandbox with the exact same env. One obvious difference between the 2 machines is the CPU. On an Intel machine, running coreutil's sha256sum $DPRINT_CACHE_DIR/plugins/dprint-plugin-json/0.17.0-4.0.0-x86_64 yields:

e6216ec40e9b486db40c2a3f62ba66cf75d0c7cd2d3825dec7a8bd38050c5bf3

and on an AMD CPU it gives:

917eb1fb932277b5aa1684f5168481552f3f0774cf999c8972b1eff5f7e936cb

Re-downloading the plugins on the same machine results in the same hash.

[Adrian]

Solved by downloading the plugins (which have a stable hash) and then pointing at the downloaded files from dprints config.