aws-vault login [profile] --prompt=pass not working since v7.0.0
aswadsun opened this issue · comments
- I am using the latest release of AWS Vault
- I have provided my
.aws/config(redacted if necessary) - I have provided the debug output using
aws-vault --debug(redacted if necessary)
I am using passwordstore store aws-vault credential. I also use its OTP functionality.
In aws-vault prior to v7.0.0 (ie. v6.6.2) I can do this command without any issue:
aws-vault login [profile] --prompt=pass
as shown in the help:
--prompt=terminal Prompt driver to use [kdialog osascript pass terminal ykman zenity] ($AWS_VAULT_PROMPT)
it support pass.
However from v7..0.0 onward, it doesn't support pass anymore. Is this intentional? Or just a bug?
Error:
aws-vault: error: enum value must be one of osascript,terminal, got 'pass', try --help
Help shown:
--prompt=PROMPT Prompt driver to use [osascript terminal] ($AWS_VAULT_PROMPT)
Right now I am rolling back to v6.6.2
Best regards,
Aswad
Read the release notes at https://github.com/99designs/aws-vault/releases/tag/v7.0.0
Can you explain the motivation behind this? The new approach is much more cumbersome to configure if you have many profiles as we now need to copy the mfa_serial into each profile as mfa_process = pass otp <mfa_serial>. This completely breaks the configuration for my entire team. I also don't understand why the other prompt drivers are getting special treatment and remain unbroken.
Motivation: #1006 (comment)
Discussion has been ongoing for a while. I'm sure not everyone will agree, but that's the decision that has been made. You're welcome to continue using v6 if you wish - it's the reason v7 is a major version bump, a major version bump signals backwards-incompatible changes.
I understand the motivations behind this change, but as I am sure you can appreciate, very few of us are in the privileged position of having the time to keep up with changelogs and issue discussions across the many tools that we inevitably end up using in any given dev environment.
May I recommend that in future you perhaps include some kind of depreciation period, and some kind of deprecation warning log message, for breaking changes like this?
At least that way it gives teams a chance to be proactive. I get that your motivations behind the change are security minded. We are using aws-vault because you have this mindset. However, unexpected breaking changes requiring reactive fixes like this are a surefire way to potentially introduce security vulnerabilities.
You're not wrong, but open source maintainers have limited time.
Major versions are for breaking changes. Don't update to a major version if you don't want to deal with breaking changes.
Feel free to actually contribute, and create a helpful message to help folks update their configs. Nothing stopping you doing that.
We have aws-vault installed with homebrew, as I am sure most people running on macs do. Homebrew doesn't care about major or minor versions of packages -- when brew upgrade is run, you get the latest version that's available.
In this case it appears that the only version of aws-vault available via homebrew is the latest, so our only way to avoid this breaking change would be to ensure that none of our users run a global brew upgrade. If they do, it doesn't look like there is a straightforward way to roll back to a previous version without manually extracting it from the repo history like this. Additionally, brew doesn't currently have any way of freezing or locking specific casks or formulae to a version, as far as I know. Perhaps maintaining a separate cask for the previous major version on brew would be a good concession here, for the next major upgrade?
Now, this is not necessarily your problem. I am not sure exactly how the cask versioning is handled within homebrew or whether you actually have any choice here. But the upshot is that in this case, we didn't get any forewarning about this breaking change, and then also had no way of either systematically avoiding it nor easily rolling back after it happened.
On this occasion, there was a way forward to restore our functionality with version 7, but in future this could cause much more disruption. Hence my suggestion for handling deprecation, which incidentally is in line with the recommendations of semver from the link you posted.
As for contributing - perhaps I or someone on my team will have the time to do that at some point. But as much as we might want to now, we simply can't. This is the only level of contribution that we are capable of providing right now.