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
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 run safe target because internally, there is no difference between overriding the target with --target or by use of the environment variable.
The scenario:
$ export SAFE_TARGET=prod
...some time later...
$ safe target sandbox
$ safe target
Specifying --target to the target command makes no sense; ignoring...
Currently targeting sandbox at https://10.10.0.4
Skipping TLS certificate validation
Uses Strongbox at http://10.10.0.4:8484/strongbox
$ safe rm -rf secret/*
# Oh-noes - prod secrets all gone!
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:
Bear in mind that fixing this doesn't magically make the implicit target TOCTOU race condition check go away, with respect to rm.
A scenario that is still dangerous:
me@term1 $ safe target sandbox
me@term1 $ safe target
Currently targeting sandbox at https://10.10.0.4
Skipping TLS certificate validation
Uses Strongbox at http://10.10.0.4:8484/strongbox
... switch to another terminal, same box ...
me@term2 $ safe target production
... switch back to where it says i'm targeting sandbox ...
me@term1 $ safe rm -rf secret/*
# oh noes!! where my prod secrets at?!
We are facing the same impediment working with various vaults.
Especially switching between terminals pointing to different vaults may result in lost or misdirected secrets, as jhunt pointed out.
I can either use "safe target " in my shell, OR use "export SAFE_TARGET="" ", but mixing them appears to be a bad idea.
But unless we remove the ~/.saferc there is no way to UNSET the "safe target".
The goal would be to be able to work with various shells, each pointing to a separate vault without the shells affecting each other.
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: