Reading secret from stdin is broken when database configuration is enabled

[wolfgangwalther]

While hacking on #2112 I noticed this is broken. Run the following in nix-shell:

echo "test" | PGRST_DB_CONFIG=false postgrest-with-postgresql-14 -f test/io/fixtures.sql \
  postgrest-run --dump-config test/io/configs/secret-from-file.config
...
jwt-secret = "test" # expected
...

echo "test" | PGRST_DB_CONFIG=true postgrest-with-postgresql-14 -f test/io/fixtures.sql \
  postgrest-run --dump-config test/io/configs/secret-from-file.config
...
jwt-secret = "" # bad!
...

I assume it's because reading from @/dev/stdin doesn't work twice... but that's what we're doing when re-loading the config from the database. That makes me wonder whether reloading the config via signal works. I guess it doesn't either... - just confirmed that. It doesn't work either.

So basically reading the secret from @/dev/stdin (as we do in the io tests) is broken in many ways. Now I wonder - do we actually officially support that at all? I can't find anything in the docs about it.

I'm leaning towards just rewriting the test-cases here and maybe adding a hint in the docs, that reading from @/dev/stdin is not supported.

[steve-chavez]

that reading from @/dev/stdin is not supported.

How about leaving it as a bug? Not so long ago I recommended @/dev/stdin to a company that didn't want the secret to be stored in any way(no env var or db or logs).

I remember testing this before and the tests helped me in not breaking it.. a regression must have happened somewhere.

[wolfgangwalther]

a regression must have happened somewhere.

That "regression" was the addition of reloading the config file. It must be broken since then. It's quite simple:

We don't make any difference between reading from a regular file and reading from @/dev/stdin anywhere in the code. Reading the same regular file twice will return the same token - but reading @/dev/stdin a second time will not.

The tests have always only accounted for that first read - but never for the reload. So it has been broken ever since.

[wolfgangwalther]

Because I needed to refactor the tests a little bit, I added a more explicit test to read the secret from stdin together with a (currently skipped) test that demonstrates the failure case in #2112.