Currently, pallet requirements are specified with a version lock which includes a timestamp and commit hash. However, the contents of the locked commit aren't authenticated. The Go Modules system does this with checksums in go.sum files, and we should also compute (and check) checksums when changing the version lock file. Maybe we should ignore any .git directories inside? (What does Go Modules do with .git directories?)
We also need checksums on file downloads. Those checksums should be stored in separate files together with forklift-package.yml files, maybe in a subdirectory of the forklift package, and a subcommand should be provided to update the checksums for a package.
It would be even more secure if we had an equivalent of Go's global checksum database to precompute checksums when a commit is published, but that's a lot of complexity for implementation and infrastructure operations - which outweighs any security concerns we have for now, so that should be considered out-of-scope for this issue.
Currently, pallet requirements are specified with a version lock which includes a timestamp and commit hash. However, the contents of the locked commit aren't authenticated. The Go Modules system does this with checksums in
go.sumfiles, and we should also compute (and check) checksums when changing the version lock file. Maybe we should ignore any.gitdirectories inside? (What does Go Modules do with.gitdirectories?)We also need checksums on file downloads. Those checksums should be stored in separate files together with
forklift-package.ymlfiles, maybe in a subdirectory of the forklift package, and a subcommand should be provided to update the checksums for a package.It would be even more secure if we had an equivalent of Go's global checksum database to precompute checksums when a commit is published, but that's a lot of complexity for implementation and infrastructure operations - which outweighs any security concerns we have for now, so that should be considered out-of-scope for this issue.