DopplerHQ/cli

[BUG] install specific version of the Doppler CLI

leonard-henriquez opened this issue · 4 comments

leonard-henriquez commented

Describe the bug

Version v3.57.0 introduced a bug that forced us to change the doppler config because it made our CI fail (thus blocking all PRs).
We had to hotfix the config and we adopted the new monorepo feature introduced by this release.
Shortly after you released a v3.57.1 that removed this feature and made our CI fail again.

How can we force our CI to use the v3.57.0 and not the latest version?
We are using dopplerhq/cli-action@v2 and it doesn't seem to have an option to install a specific version of the doppler CLI.

That could be really useful, particularly if you frequently introduce breaking changes

Piccirello commented

Sorry for the trouble here. We explicitly try to introduce as few breaking changes as possible. In this case, v3.57.0 had a bug that resulted in the failures you were seeing. We rolled this change back in v3.57.1 so that we could properly investigate and fix it. I would expect monorepo support to be reintroduced within the next week. Once re-added, it'll be backwards compatible with existing configs.

leonard-henriquez commented

Even if you try not to introduce breaking changes, it seems that it does happen.
If you introduce a security breach by accident in a new version we will have no way to opt out?
Allowing to use a specific version of the CLI seems like a must have feature.

leonard-henriquez commented

I am a bit concerned about the safety and the reliability of this tool.
This is really not reassuring for a security solution that inject secrets in production environments.
The recent change log give the impression that you experiment on production:

  • 3.57.0 (3 weeks ago) -> Add support for monorepo-friendly structuring in doppler.yaml setup file
  • 3.57.1 (2 weeks ago) -> Temporarily revert monorepo support in setup command
  • 3.58.0 (5 days ago) -> Some changes
  • 3.58.1 (?) -> Release doesn't seem to exist anymore
  • 3.58.2 (2 days ago) -> Same changes as 3.58.0 + Note: this is a re-release to test our publishing process and is identical to v3.58.0.
  • 3.58.3 (2 days ago) -> Same changes as 3.58.0 + Note: this is a re-release to test our publishing process and is identical to v3.58.0.

How can I defend my application from supply chain attacks if I can't force using a specific version ?
Do you plan to address this issue?

PS: do you have any news on the re-introduction of monorepo support?

Piccirello commented

Thank you for your note. I can understand your curiosity given that the versions have the same changelog notes. We were moving our release infrastructure from GitHub classic Personal Access Tokens to fine-grained tokens. This took a couple tries to get the permissions right, given that fine-grained tokens have far fewer perms. We also try to never unpublish releases, hence the multiple versions and confusing changelog.

We believe that the best way to ensure the security of the CLI is for customers to always be on the latest version. This follows the approach taken by Google Chrome, SaaS solutions, and even your OS. Remaining on an outdated version exposes you to vulnerabilities that may have been fixed in the latest version of our CLI. We don't currently have any plans to change this behavior.