Values from .env are propagated to executed process

[ruuda]

Vaultenv reads a .env file, if present, to get it’s own configuration (e.g. VAULT_HOST or VAULTENV_CONNECT_TLS). However, it also makes everything set by the .env file available to the spawned process.

This happens because the environment includes cLocalEnvVars:

vaultenv/app/Main.hs

Line 396 in 285463d

then removeBlacklistedVars $ secretsEnv ++ cLocalEnvVars originalContext

which is populated from among others the .env file:

vaultenv/app/Main.hs

Lines 265 to 278 in 285463d

	envFileSettings <- readConfigFromEnvFiles
	cliAndEnvAndEnvFileOptions <- parseOptions localEnvVars envFileSettings
	let envAndEnvFileConfig = nubBy (\(x, _) (y, _) -> x == y)
	(localEnvVars ++ concat (reverse envFileSettings))
	if getOptionsValue oLogLevel cliAndEnvAndEnvFileOptions <= Info
	then print cliAndEnvAndEnvFileOptions
	else pure ()
	httpManager <- getHttpManager cliAndEnvAndEnvFileOptions
	let context = Context { cLocalEnvVars = envAndEnvFileConfig

I’m not sure if this is intentional or not, but it did leave me confused for a bit, because Vaultenv complained

[ERROR] Found duplicate environment variable

for a variable (unrelated to Vaultenv) that I happened to define in my .env, and also wanted to set with a secret. For my use case, I don’t want Vaultenv to pass what’s in .env along to the spawned process. (The .env happens to be there for local development, and I want to write a script that executes migrations in production, so it fetches the PGUSER and PGPASS for the production database.)

I’m not sure if this behavior is intentional. If it is, I would document it in the readme, and possibly add a way to disable it (though --no-inherit-env or --inherit-env-blacklist are fine for working around it).

[ruuda]

Actually, --inherit-env-blacklist is not appropriate due to a bug ... it also prevents variables set by Vaultenv itself from propagating to the spawned process. So in this situation:

• .env exists and sets PGPASS and PGHOST
• My secrets file sets PGPASS=app/.../postgres#PGPASS
• I call vaultenv from a script that sets PGHOST to a value that should override whatever is in .env.

It now seems impossible to actually get the correct PGPASS and PGHOST into my application:

• If I set --inherit-env-blacklist PGPASS, then I don’t get any PGPASS at all in the spawned process.
• If I set --no-inherit-env, then I get no PGHOST in the spawned process.

I can work around this by spawning env.

This could be fixed by moving the removeBlacklistedVars after the ++ here:

vaultenv/app/Main.hs

Line 396 in 285463d

then removeBlacklistedVars $ secretsEnv ++ cLocalEnvVars originalContext