tom-doerr
[Feature Request] Specify API keys using environment variables
Hi @tom-doerr!
It would be great, in order to store them in a safer way.
Thanks for your help.
Why would it be safer to have them as environment variables? Wouldn't that mean that every program can just pull them from the environment? Not saying you aren't correct, just genuinely curious. I believe the openai package already reads the API-key from the environment if it is set there, I think the question is just if we are overwriting it or an error is thrown if it's not set in the config: https://github.com/tom-doerr/zsh_codex/blob/7f1def91142dc0b66bf8010315000e23c1201355/services/services.py#L47C34-L47C41
Do you want to investigate? I would merge a PR for this
Dear Tom, thank you for your response.
Based on my experience, utilizing environment variables instead of configuration files can enhance security by mitigating the risk of accidental permission errors. In my workflow, I retrieve the OPENAI_API_KEY from AWS Secrets Manager during shell startup. This approach streamlines the process of transferring my dotfiles to different systems and facilitates sharing.
I am currently working on a fork of your repository to implement this feature. The functionality will prioritize checking for the environment variable and, if absent, defaulting to the configuration file.
Furthermore, I'd like to implement the possibility to eliminate the config file entirely, particularly by designating a service (e.g., OpenAI) as the default.
I would appreciate your feedback on these proposed changes.
Sounds good! How about making the the config file optional? Would hate to break people's setups.
Hi! It is a practice, how good or bad to provide secrets as environment variables. What bad practice is to have the same secret in thousands of places as that increases the likelihood for leaks. Besides that it is a good practice to keep such config files in a .my-dots repository. Storing a config that contains a secret in git and then accidentally pushing to a remote is an extreme violation of basic security discipline. If an app/library is already handling a certain env variable, the cleanest is to allow the lib to handle it. You wrote a nice and simple tool, but anything you do in life is a liability :) ... And attaching too much risks to it is increasing your liability.
Maybe as inspiration, have also a look at https://github.com/evalstate/fast-agent, they keep AI agent secret keys in separate file
Keeping the secrets separated, but not in env would be also a usecase, where for instance you are using for OpenAi for most apps the env key, but for zsh_codex you would use a separate key.
Hope this helps
