Deno: Small concern regarding integrity checking & lock files

[redbar0n]

Re: https://deno.land/manual/linking_to_external_code/integrity_checking

Context:

A typical workflow will look like this:

// Add a new dependency to "src/deps.ts", used somewhere else.
export { xyz } from "https://unpkg.com/[email protected]/lib.ts";

Then:

# Create/update the lock file "lock.json".
deno cache --lock=lock.json --lock-write src/deps.ts

Runtime verification:
Like caching above, you can also use the --lock=lock.json option during use of the deno run sub command, validating the integrity of any locked modules during the run. Remember that this only validates against dependencies previously added to the lock.json file. New dependencies will be cached but not validated.

My small concern is that someone (inevitably?) will import a new remote module, but then forget to update the lock file. Then that would lead to the remote module by default being cached and loaded, without it being integrity checked first. (If I have understood the docs correctly). It seems like it could easily open up that potential attack vector again (mentioned in the introduction). Wouldn't it be better to (1) give a warning that this module is not added to the lock file? And perhaps (2) provide an easy option to add it to the lockfile then and there?

Another thought could be to (3) enable integrity checking by default, and rather make an unlock-file, where devs would specify modules which should _not_ be integrity checked. In the spirit of secure-by-default, and whitelisting over blacklisting (the lock file is currently a kind of blacklist; a list of files not to be trusted by default).

[kevinkassimo]

(1) sounds like a good way to go, probably could be accompanied with a new flag e.g. --lock-strict=lock.json to simply fail on dependencies not present in the lockfile.

[ry]

Thanks for raising this.

(1) is certainly the easiest immediate fix. But I hope we might be able to enable lock files by default in the future.