The HashicorpVault client used by VaultSigner to import_ a public key or sign, needs a vault address and a token. We expect users to provide both via specific envvars known to the client, and so do the tests:
|
VAULT_ADDR = http://localhost:8200 |
|
VAULT_TOKEN = test-root-token |
But it turns out that the tests work even if the envvars are not available to VaultSigner, because:
- above VAULT_ADDR is the default address, which the client falls back to, if the env var is not set, and
vault server -dev (in init-vault.sh) secretly writes the token to a ~/.vault-token file, which the client falls back to, if the env var is not set
This is not necessarily an issue but a bit surprising, so I think a note in VaultSigner code doc and tox.ini might be fix enough.
Alternatively, we can set VAULT_ADDR to a non-default port and start the test server like so:
vault server -dev \
-dev-listen-address="${VAULT_ADDR#http://}" \ # unlike VAULT_ADDR this option does not want the protocol prefix
-dev-root-token-id="${VAULT_TOKEN}" \
-dev-no-store-token \
&
The HashicorpVault client used by VaultSigner to
import_a public key orsign, needs a vault address and a token. We expect users to provide both via specific envvars known to the client, and so do the tests:securesystemslib/tox.ini
Lines 122 to 123 in 5e734e4
But it turns out that the tests work even if the envvars are not available to VaultSigner, because:
vault server -dev(ininit-vault.sh) secretly writes the token to a~/.vault-tokenfile, which the client falls back to, if the env var is not setThis is not necessarily an issue but a bit surprising, so I think a note in VaultSigner code doc and tox.ini might be fix enough.
Alternatively, we can set VAULT_ADDR to a non-default port and start the test server like so:
vault server -dev \ -dev-listen-address="${VAULT_ADDR#http://}" \ # unlike VAULT_ADDR this option does not want the protocol prefix -dev-root-token-id="${VAULT_TOKEN}" \ -dev-no-store-token \ &