Security issue with depreciation of .env

Bug description:

Cannot use .env to set secrets, the superseded method is insecure

the create secrets (as i understand it) allow others to use your api keys to run your programs. I do not want this behaviour, i want to create a .env that allows the code to be public but each user must use their own key. Im not funding someone elses openai calls.

It is actually the opposite, replit secrets only let you use it, if someone else runs your repl the secret will not be availabile. It is exactly like .env but instead of a text file it give you a GUI

3 Likes

As @dragonhunter1 said, Secrets only work in the workspace. Please mark his post as the solution.

2 Likes

ok, thanks for the clarification.

I dropped into shell and created a .env when i was blocked. Being an “old school” programmer i learned the original Klingon version of Python, called COBOL. so when blocked, i go to cli.

now do i now get rid of the .env in favor of the correct method. It still exists, my keys are still available but rm .env doesnt find it, nor does ls -a

1 Like

There is no .env, and pid1 (the init process Replit runs in repl Docker containers) will delete any .env files you create. You don’t need to get rid of it or anything

1 Like

ok but i cannot change my api key because when i try to add that keypair though secrets, it tells me that it already exists.

Is there a way of seeing and deleting current secrets?

i think ive borked things. Its moved my .env to secrets, but secrets doesn’t know the variable exists.

when i try to create my very first variable in secrets i get this

edit:Ok NVM, ive fixed it by forking the original and doing things the proper way.

Thanks for the help

3 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.