Describe the bug
When supabase secrets set --env-file <file> cannot parse a line of the file, the
error message includes the file's content. The file exists only to hold secrets, so
this prints secret values to the terminal, and from there into CI logs, shell
scrollback and AI-assistant transcripts.
We hit this in production. The file held a bare token (no KEY= prefix) by
mistake. The command failed, as it should, but the error printed the live token
and we had to revoke and rotate it. The same thing happens with a value whose
closing quote is missing (KEY="value).
To reproduce (fake values only)
printf 'eyJhbGciOiJIUzI1NiJ9.FAKE-NOT-A-REAL-TOKEN.signature\n' > /tmp/bad.env
supabase secrets set --env-file /tmp/bad.env --project-ref <any-project>
printf 'MY_KEY="fake-value-without-closing-quote\n' > /tmp/bad2.env
supabase secrets set --env-file /tmp/bad2.env --project-ref <any-project>
In both cases the error output contains the fake value.
Expected behavior
The error names the file and the line number (for example
/tmp/bad.env:1: expected KEY=VALUE) and never prints the line's content. A parser
for a secrets file should treat every byte of it as secret, including in error
messages.
System information
- Supabase CLI version: 2.78.1
- OS: Linux (Ubuntu, x86_64)
Additional context
Our workaround is to set Edge Function secrets through the Management API
(POST /v1/projects/{ref}/secrets) with a JSON body built in memory, and to block
secrets set --env-file in our automation. The same "don't echo the input on a
parse error" rule probably applies to any other CLI command that reads an env file.
Describe the bug
When
supabase secrets set --env-file <file>cannot parse a line of the file, theerror message includes the file's content. The file exists only to hold secrets, so
this prints secret values to the terminal, and from there into CI logs, shell
scrollback and AI-assistant transcripts.
We hit this in production. The file held a bare token (no
KEY=prefix) bymistake. The command failed, as it should, but the error printed the live token
and we had to revoke and rotate it. The same thing happens with a value whose
closing quote is missing (
KEY="value).To reproduce (fake values only)
In both cases the error output contains the fake value.
Expected behavior
The error names the file and the line number (for example
/tmp/bad.env:1: expected KEY=VALUE) and never prints the line's content. A parserfor a secrets file should treat every byte of it as secret, including in error
messages.
System information
Additional context
Our workaround is to set Edge Function secrets through the Management API
(
POST /v1/projects/{ref}/secrets) with a JSON body built in memory, and to blocksecrets set --env-filein our automation. The same "don't echo the input on aparse error" rule probably applies to any other CLI command that reads an env file.