-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
safe --target target
sometimes makes sense
#224
Comments
Bear in mind that fixing this doesn't magically make the implicit target TOCTOU race condition check go away, with respect to A scenario that is still dangerous:
|
We are facing the same impediment working with various vaults. I can either use "safe target " in my shell, OR use "export SAFE_TARGET="" ", but mixing them appears to be a bad idea. The goal would be to be able to work with various shells, each pointing to a separate vault without the shells affecting each other. |
I share the concerns stated above. Please make |
Obviously,
safe --target <x> target
doesn't make a lot of sense on its own, but there are conditions where it does make sense.The most crucial is when the safe target is being specified by the SAFE_TARGET environment variable. In this case,
safe
outright lies to you when you runsafe target
because internally, there is no difference between overriding the target with --target or by use of the environment variable.The scenario:
In this case,
safe target
should return whatever target will be used when safe is called in that environment.Similarly, when running
safe target --json
in order to get the current target information in a json format, safe currently gives the .saferc 'current' target details, not the target in that environment. It even makes more sense to support the explicit--target <x>
option in this case for when you want to read details about a specific target without changing the actual target.The text was updated successfully, but these errors were encountered: