Lockfiles are a very important piece that is currently missing from proto. They help to avoid man-in-the-middle attacks by verifying downloads are legitimate and haven't been tampered with, as well as locking a configured version to a resolved version for all users.

Internally we already verify this information and track it in the manifest, but this is hidden away from the user. Additionally, these checksums and other metadata are not included in the repository, so this cannot be enforced and verified across different machines (local vs ci, etc) in a persistent manner.

So what would lockfiles look like in proto?

Enabling lockfiles

Lockfiles are not enabled by default and will be an opt-in feature. To use a lockfile, set lockfile = true in .prototools settings.

[settings]
lockfile = true

When enabled, a lockfile will be created relative to a .prototools in which its locking. The lockfile is not created for every .prototools; only those that have set lockfile = true in their settings.

This setting will be ignored for ~/.prototools and ~/.proto/.prototools.

Lockfile format

The lockfile will be named .protolock. The actual format/structure of the lockfile does not matter, but at minimum we'll capture the following information:

• Tool ID
• Unresolved version (requirement, etc)
• Resolved version
• Checksum
• Backend

Command integration

The following changes would be made to existing commands to support lockfiles.

proto install (multiple)

Without lockfile: It will continue to work as it does currently. Versions in .prototools will be resolved and the tools will be installed.

With lockfile: Versions in .prototools will not be resolved, and instead the version to install will be extracted from the lockfile. The tool will then be installed and also verified against the checksum in the lockfile.

If the version in .prototools has changed, and it does not match the version in .protolock, we will error unless --update-lockfile is passed.

proto install <tool> (single)

Without lockfile: It will continue to work as it does currently. The "latest" version will be resolved and the tool will be installed.

With lockfile: The "latest" version will not be resolved, and instead the version to install will be extracted from the lockfile. The tool will then be installed and also verified against the checksum in the lockfile.

The --update-lockfile option can be passed to bypass the lockfile, resolve to latest, and then update the lockfile to the new version.

proto install <tool> <version>

Since an explicit version is provided, that version will be resolved, and the tool will be installed. This ignores the lockfile entirely, as we explicitly want to install this tool + version.

This does not update a lockfile if it exists, nor would --pin update the lockfile, as that's for pinning a version to .prototools. The --update-lockfile option will need to be passed to update the lockfile.

outdated

If a version comes from a lockfile, add a label denoting it.

outdated --update

Without lockfile: It will continue to work as it does currently. Newer versions will be written to each .prototools.

With lockfile: If a locked version is being updated, it will trigger an error. There's no way around this, as we're unable to update the lockfile from this flow as we do not have checksums. Users will need to manually edit their .prototools and re-run proto install.

run

Without lockfile: It will continue to work as it does currently. The version to run with will be detected by scanning the file system.

With lockfile: The locked version will be the version to run with, assuming a version was not detected from a higher directory.

status

If a version comes from a lockfile, add a label denoting it.

Other commands

All the other commands do not interact with the lockfile.

Comments?