storing api keys in plain text

[bachittle]

Validations

• I believe this is a way to improve. I'll try to join the Continue Discord for questions
• I'm not able to find an open issue that requests the same enhancement

Problem

I don't like that all the API keys are stored in plain text in a JSON file at the user root. I know that this is required for VSCode, and every other plugin that uses API has to do this. It just doesn't sit right with me.

Solution

At the very least, put a .gitignore at the root of .continue to make sure config.json doesn't get indexed. It may also be possible to write external scripts that encrypt the config.json if the user wants to be security-conscious.

[noamross]

Ideally one should be able to use environment variables for API keys and keep them out of the config entirely.

[rashabarbar]

Another vote. Support for environment variables or alternative secure storage would be a significant improvement.

[diogovalada]

I too would support the idea of retrieving the API keys from the environment variables.

[boennemann]

I also feel like .continuerc.json is pretty much impossible to use, if I can't pull in secrets. Otherwise I can't commit this, when the whole point of the file is to share setup with the team?
Or is that not the point? Should I gitignore this and let everybody else copy/paste this?

[ctwardy]

Putting this into config.ts worked for us, allowing us to write things like ${USERNAME} and ${OPENAI_API_KEY} into our config.json and project-specific .continuerc.json files.

 /**
   * Recursively replace environment variable placeholders in an object.
   * 
   * This function traverses through the provided object and looks for strings 
   * containing placeholders in the format `${VAR_NAME}`. It then replaces 
   * these placeholders with the corresponding values from `process.env`. 
   * If the environment variable is not found, it replaces the placeholder with an empty string.
   * 
   * @param obj - The object in which placeholders should be replaced. This can be a deeply nested object.
   */
  const replaceEnvVars = (obj: any) => {
    for (const key in obj) {
      if (typeof obj[key] === 'string') {
      // Replace placeholders in the format ${VAR_NAME} with the value from process.env
        obj[key] = obj[key].replace(/\$\{(.+?)\}/g, (_: any, varName: string | number) => process.env[varName] || '');
      } else if (typeof obj[key] === 'object' && obj[key] !== null) {
      // Recursively call replaceEnvVars for nested objects
        replaceEnvVars(obj[key]);
      }
    }
  };

  const newConfig = JSON.parse(JSON.stringify(config)); // Create a deep copy of the config object
  replaceEnvVars(newConfig);
  return newConfig;

➛ A good bit of that was written by Continue/GPT as I don't normally typescript. :-)

Probably this should be pulled into the codebase, not required of everyone's custom config.
But I'm not sure where.

Note: Continue handles comments in config.json, but not .continuerc.json. I'll make a quick ticket for that.

[RomneyDa]

@bachittle @noamross @rashabarbar @boennemann @ctwardy thoughts on this implementation?

• Environment variables will be checked for in some specific config inputs like URLs and API keys (any others?)
• They can be injected into those strings using mustache format e.g. {{ ENV_VAR_NAME }}
• by default, the IDE checks .env files at the root of the directory
• or, if envFiles = ["URI_1", "URI_2"] etc. is specified in config.json it checks those
• If a specified var is not found, will throw error on config load and show in config issues page

[RomneyDa]

Would note that this issue is solved way more robustly for teams by Continue for Teams (in beta) since in this case would still need to share config files around and stuff. But this would be good for

• Individual developers with no team (common)
• Cases where within one team, one developer would use one model and another another, etc. (possible edge case for now)

[ctwardy]

@bachittle @noamross @rashabarbar @boennemann @ctwardy thoughts on this implementation?

Those look good - I'd neglected to support .env but it really should. envFiles is a great idea too, and moustache-format (mumbo-format?) would be a sensible change.

In addition to URLs and API keys, I'd suggest:

• Common user vars like USERPROFILE, HOME, USERNAME. For example, we use "userToken": "${USERNAME}", and "caBundlePath": [ "${USERPROFILE}/.continue/cacert.pem" ]

Anything we do now can be done with those. And simple is good as extensions are boundless. But they suggest two common cases:

• CONTINUE_* like CONTINUE_USERTOKEN
• CA_BUNDLE_PATH or similar, as certs are likely to be a common issue.

We're tracking the team version and will be interested when we can run the server behind our firewall. Totally understand that's not your first priority. But add a vote for the backlog.

[Joilence]

@RomneyDa , the solution looks great. Only:

by default, the IDE checks .env files at the root of the directory

If directory meaning "current workspace / working directory", there might be a risk.

It seems like a trend that coding assistance tools, including Continue, would build a map of the repo and inject files as context as LLM sees fit (smart context), and it's a risk that .env file could be sent to some remote model provider when the user ask something like "introduce me the structure of this project". Let the tool ignore dot files is sometimes a good practice, but can't promise every tool will do this.

[RomneyDa]

@Joilence good callout, I think to answer your question, for indexing and all directory walking including repo map generation, these files are ignored by default including .env files and anything in .gitignores and .continueignores:
https://github.com/continuedev/continue/blob/2c597764cac076a6342625273e43f203b74f2da6/core/indexing/ignore.ts
also check out the walkDir function

.env would only be checked when parsing config in that solution

@ctwardy Only supporting CONTINUE_ env variables with mustache templating could be a pretty solid solution. And maybe a select few others like HOME_DIR etc., agree