You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cloudify CLI stores user password in plaintext #910
As discussed with @isaac-s elsewhere, this isn't necessarily a bad behaviour, but it does not provide the flexibility to circumvent this on a shared system.
Potential workarounds would include:
allow reading passwords from some environment variable
This means, specifically, allowing profile creation without passwords, and implementing a read of an environment variable for user passwords (or user-inputted passwords)
@esmcelroy Worth noting that the env var approach is not a good workaround if we're positing that the multiple users have the ability to read each others home directories, etc, as that implies they can probably also read /proc//environ. The prompting for a password could be good though.
Another potential implementation could see the user prompted for a password on first run - at which point, the CLI requests a token, which it can cache with a timeout timestamp, creating a session that will remain valid for the length of the token. On token expiry, it requests the user password again
@esmcelroy Perhaps better for that approach would be something similar to the old gmail app-specific-passwords- probably in the form of tokens, but then that would allow issuing something that, e.g. a CLI on a shared machine could use which could later be revoked/disabled.
I'm not sure what the internal visibility on this issue is at the moment, but I'll pass it on for attention.
Activity
isaac-s commentedon Jan 26, 2019
@esmcelroy thank you. I have escalated internally.
esmcelroy commentedon Jan 28, 2019
As discussed with @isaac-s elsewhere, this isn't necessarily a bad behaviour, but it does not provide the flexibility to circumvent this on a shared system.
Potential workarounds would include:
esmcelroy commentedon Jan 28, 2019
This means, specifically, allowing profile creation without passwords, and implementing a read of an environment variable for user passwords (or user-inputted passwords)
geokala commentedon May 21, 2019
@esmcelroy Worth noting that the env var approach is not a good workaround if we're positing that the multiple users have the ability to read each others home directories, etc, as that implies they can probably also read /proc//environ. The prompting for a password could be good though.
esmcelroy commentedon Sep 27, 2019
Another potential implementation could see the user prompted for a password on first run - at which point, the CLI requests a token, which it can cache with a timeout timestamp, creating a session that will remain valid for the length of the token. On token expiry, it requests the user password again
geokala commentedon Sep 27, 2019
@esmcelroy Perhaps better for that approach would be something similar to the old gmail app-specific-passwords- probably in the form of tokens, but then that would allow issuing something that, e.g. a CLI on a shared machine could use which could later be revoked/disabled.
I'm not sure what the internal visibility on this issue is at the moment, but I'll pass it on for attention.