--no-latest-check and good defaults about sops HOT 6 CLOSED

I think I found an approach that will satisfy everyone: the latest check is no longer invoked at every run, but only when sops is invoked with the show version flag (-v, -V or --version). I also added a bit of logic to show the right instruction for linux or macos.

Is this satisfactory?

from sops.

I can agree with the concern (and lack of usefulness) and having tons of machines perform the latest check. However, it's still a very useful thing to have for regular users, I think.

I'm assuming --no-latest-check is not good enough for you, otherwise you wouldn't have created this issue. Disabling the check entirely seems drastic. Forking means you have to maintain your own branch with security fixes and new features. If the command line flag is not good enough, the latest check could also be controlled by environment variable or configuration file. We already support a .sops.yaml file in the latest version, it would be trivial to add a config option to it, assuming you're fine with deploying a configuration file everywhere.

from sops.

Things we can do:

• if rand() % 10 == 0: run the latest check on 10% of the time
• if pwd.getpwnam(os.getenv("USER")).pw_uid < 1000: disable the check if the user id is lower than 1000 (need to check on macos)
• create a sops-decrypt cli that only does decryption and none of the other fancyness

from sops.

Thanks for the response.

I'm not sure doing "Russian Roulette" or UID based checks would be ideal, the former would make the product behave randomly and instead of seeing a repeatable error like we did where every invocation took longer than expected, hair would be ripped out wondering why only a percentage of invocations did.

For now, I think the best approach is that it remains the default. We'll use --no-check-latest when not using the API on servers, and leave it enabled for when engineers use it, and we'll add proxy support as a pull request shortly.

from sops.

I think there is a valid case for making this smarter. Not only does it not make sense to perform this check on servers, it also doesn't make sense to recommend a pip update when the user installed sops via homebrew.

Something shall be done about it.

from sops.

Err, wow, yeah. We were just going to work around the status quo.

from sops.