6 ms·
Fun game, but it showed the lack of security hygiene employed by the game writer. It said `cat ~/.zshrc` was bad because it would share tokens and secrets, but
by spurgelaurels 4mo ago
Fun game, but it showed the lack of security hygiene employed by the game writer. It said `cat ~/.zshrc` was bad because it would share tokens and secrets, but I would never put secrets into my shell rc.
- otabdeveloper4 4mo agoHaving "tokens and secrets" at all is a lack of security hygiene.
- nish__ 4mo agoWhere would you put them?
- setopt 4mo agoPresumably a CLI-accessible password manager (like `pass`) or a GPG-encrypted file (like a netrc-style `~/.authinfo.gpg`).
- Hackbraten 4mo agoInto `pass`, for example: https://news.ycombinator.com/item?id=48108207 https://news.ycombinator.com/item?id=48108207
- analog_daddy 4mo agoJust curious, any reason to prefer using age (you mentioned that you would prefer it if starting over), over something like keepass? I am currently using keepass-cli and only reason i did not use age even though i found it was that it was new to me and I never heard of it (probably not the best reason, but in this era might be a reasonable thing to stick to devil you know). So curious about your take on this.
- freedomben 4mo agoI put mine in various aes encrypted file (like `~/.secrets.aes`) and then source it explicitly when needed with: . <(aescrypt -d -o - ~/.secrets.aes) I have a handful of aliases/functions to make it more smooth, but that's the core.
- maccard 4mo agoWhere are those aliases stored?
- AnyTimeTraveler 4mo agoIn that AES encrypted file. It's a shellscript that they encrypted. They decrypt it and feed the decrypted output immediately into the shell, to be sourced. That encrypted secrets file could contain any shellscript, so the aliases are stored in there, together with the API-Keys and passwords.
- freedomben 4mo agoThe AES encrypted file has some, plus a bunch of exported env vars. I do keep one function in my ~/.bashrc to make it simpler to invoke so I can do `source-secret ~/.secrets.aes`: source-secret() { if [ -z "$1" ]; then echo "Need filename to source" elif ! [ -f "$1" ]; then echo "File '$1' does not exist" elif ! which aescrypt >/dev/null 2>&1; then echo "Could not find required dependency 'aescrypt'" else . <(aescrypt -d -o - "$1") fi }
- isityettime 4mo agoAnywhere else? Password managers have CLIs, operating systems have their own secure storage, and lots of command line apps can store secrets in the OS's secure storage (Windows Credential Store, Secrets Service or KWallet on Linux, macOS Keyring). Project-specific secrets can be stored locally via something like SOPS or remotely with something like Hashicorp Vault or AWS SecretsManager. Applications that have secrets to manage (e.g., Emacs) or are partly about secrets management (e.g., GnuPG, OpenSSH) all store their secrets somewhere else and have secure (not plaintext, sometimes not even on disk) storage options available. There's no reason to store secrets in plain text in your shell configuration. Practically any choice you can think of is a better one. Even if you did, there's no reason you couldn't store them in a more specific file that ~/.zshrc sources, and let LLM agents read zshrc but block access to the file containing your secrets. (I wouldn't rely on permissions prompts for this, though, lol.)
- SOLAR_FIELDS 4mo agoAnother more secure pattern: have different shell profiles that just go dynamically inject secrets from a secrets manager. Nix is a good tool for this. You have various shell profiles configurations that call your password manager cli at bootstrap (eg new terminal tab). You auth and at bootstrap of the terminal time the secret is dynamically fetched from the password manager and injected into an env var. this has advantage over other approaches mentioned here in that the secret is never stored at rest on the end user’s machine only used in flight
- godelski 4mo agoLiterally anywhere else! Your dotfiles should be publishable to github. If they aren't you're doing them wrong. A good thing to do is organize. You can actually load different files. Here's a pretty common pattern that you'll find and it'll illustrate how to do other things if [[ $(uname) == "Darwin" ]]; then source "${INSERT_SOME_DIR}/osx.zsh" elif [[ $(uname) == "Linux" ]]; then source "${INSERT_SOME_DIR}/linux.zsh" fi You do this for loading based on the operating system. You might want some aliases, commands, or other routines in one but not the other. For example, in my linux one I have stuff for cuda paths. You can do all sorts of things too, like make a (generically named) work file, which you don't publish to github but you load it if it exists. Then you can put all your work related aliases there and not contaminate anything else. Something like `[[ -a ${INSERT_SOME_DIR}/work.zsh ]] && source ${INSERT_SOME_DIR}/work.zsh`. You shouldn't really load secure keys this way, but others had good answers so I thought I'd at least share a more general pattern since it isn't as well known among the less terminally inclined.
- analog_daddy 4mo agoOkay. Here is a pattern i follow everywhere in my init files for almost every program. Define two key env vars. $DOTFILES and $ECORP. The first is path to your personal set of dotfiles. The second is path to your corporate specific dotfiles. On personal pc no need to define the $ECORP var in shell init. On work pc define that var. based alone on that you can conditionally do almost anything. - shell source files/aliases - vim/editors enable disable plugins based on existence of env vars. - define shortcuts in file manager. - and i add the following to my main $DOTFILES .gitignore. # Any file that contains the following will be ignored. # Used to ignore files in corporate environment *ECORP* *ecorp* Based on multiple years across different setups, using environment variables was the most reliable option since I have been in places where there are restrictions on where my init files can be placed and having to change a shit ton of paths in my dotfiles or just keeping a different branch for work and personal (and making sure they stay in sync) was too much of a hassle. Additionally, maintaining hygiene is essential, where I only use a Read Only PAT token on my personal dotfiles in workenv. That way, there is no accidental way I would be able to push from my workenv.
- hk__2 4mo ago
- andrewaylett 4mo agoI've recently been enjoying https://fnox.jdx.dev/ https://fnox.jdx.dev/.
- londons_explore 4mo agoPlenty of people would. But then I guess they're in env and probably already available to Claude
- isityettime 4mo agoJust aside from all of the security concerns, this is the wrong place to define global environment variables for zsh in the first place! That would be ~/.zshenv. So even if you're clueless about storing secrets in plain text and exporting them as env vars everywhere, ~/.zshrc should still be clean.
- shlewis 4mo agoI don't do this myself, but I can also see how many would do this.
- arowthway 4mo agoAlso, there's nothing inherently insecure about feeding secrets to an LLM, it's only one element of the lethal trifecta.