feat: allow opencode-claude-max-proxy version specification

[braydenbabbitt]

This is to allow users to pin a version of opencode-claude-max-proxy to avoid supply-chain attacks if opencode-claude-max-proxy is compromised and publishes a malicious version. (See "Widespread Supply Chain Compromise Impacting npm Ecosystem")

Ever since this up-tick in supply-chain attacks on npm, I personally have switched to pinning every dependency everywhere to specified version, so a new version cannot be installed/executed without me manually updating. I would like to be able to do that with this plugin and its dependencies, and I'm sure many others would benefit from this as well.

Currently it is only possible to pin the version of this plugin, and not opencode-claude-max-proxy

[ianjwhite99]

Appreciate your work and input on this. Wanted to get some more clarity or your thoughts on the following:

Currently, each version of this plugin updates with a patch or minor version change as the proxy dependency updates. Those changes are refelected in the CHANGELOG.md.

If there were a supply chain attack on a specific proxy version, would it not make sense to just version-pin the current plugin that was bundled with an uncompromised proxy version rather than introducing the additional complexity of version-pinning the proxy inside of this plugin?

[braydenbabbitt]

Appreciate your work and input on this. Wanted to get some more clarity or your thoughts on the following:

Currently, each version of this plugin updates with a patch or minor version change as the proxy dependency updates. Those changes are refelected in the CHANGELOG.md.

If there were a supply chain attack on a specific proxy version, would it not make sense to just version-pin the current plugin that was bundled with an uncompromised proxy version rather than introducing the additional complexity of version-pinning the proxy inside of this plugin.

@ianjwhite99

Those are excellent questions. The reason that I took the approach in this PR is because this is my first contribution to the project. So, because of that fact, I didn't want to make my change burdensome on the maintainers or users, and I wanted it to be completely backwards compatible so that it was a transparent update for anyone who wanted to continue to use the plugin as before.

If I were the owner of the project, my approach would be completely different. I would change the dependency on the proxy to be pinned to an exact version number, and I would only manually update the version number on an as-needed basis. This introduces more work for the maintainers that I was trying to avoid imposing upon you and any other maintainers.

From what I've seen, every supply chain attack has been released in a patch version and therefore the only way to truly defend against a supply chain attack that originates in a dependency is to pin the dependency to an exact version number and only manually update to known safe versions.

The reason I would proactively pin the version number rather than reactively pin the version number is that if a project waits until a supply chain attack has been found, then it is possible that users will have installed the malicious version through the dependency before the version can be pinned to a safe version.

[calebdw]

Honestly I think this is overkill and a knee-jerk reaction to recent events---supply chain attacks should be solved at the npm level, not by every package using env vars to pin versions for all of their deps

[braydenbabbitt]

Honestly I think this is overkill and a knee-jerk reaction to recent events---supply chain attacks should be solved at the npm level, not by every package using env vars to pin versions for all of their deps

@calebdw

I actually opened this up before the Axios issue. I've been shifting my approach to every tool/library that I use to make sure that I only use things with dependencies with pinned versions for over a year now.

As I explained in my other comment, the environment variable approach was simply to avoid causing backwards compatibility issues for users, and avoid adding maintenance burden to the maintainers, especially since this would be my first contribution to the project.

I believe the better approach would be to pin the dependency in this project, and only update the version on an as-needed basis, but I didn't want to impose that burden on the maintainers

[ianjwhite99]

After some consideration, I think we'll probably continue the course of manually bumping the version number as needed for now. I don't want to overcomplicate the plugin setup and management. Thank you for your work on this

[braydenbabbitt]

After some consideration, I think we'll probably continue the course of manually bumping the version number as needed for now. I don't want to overcomplicate the plugin setup and management. Thank you for your work on this

Thanks for taking a look at it and considering it. I appreciate all y'alls work on this tool too. It's a life-saver