Changes key loading helpers used by admin ceremony and metadata update commands to provide an option to the user to load a public key from HashiCorp Vault into TUF metadata.
TODO:
update to securesystemslib 1.0.0 to use VaultSigner (this will require a major sweep through the code base)
adopt change in existing metadata update and sign tests (currently, only helper tests are updated)
add new tests
re-think "ambient" config needed by HashiCorp client. options are:
tell user to provide config out-of-band, e.g. via rc file, env vars, etc. as expected by securesystemslib
prompt user for config, and re-export in a form supported by securesystemslib
tuf-on-ci does the former (see "Prepare your local environment" in its docs/ONLINE-SIGNING-SETUP.md (cc @jku, who might be willing to share some wisdom )
tuf-on-ci does the former (see "Prepare your local environment" in its docs/ONLINE-SIGNING-SETUP.md (cc @jku, who might be willing to share some wisdom )
I'm still not sure if that was the best idea:
on one hand once the KMS access is setup it works really smoothly, is not much code in the signing tool itself, and is very reliable (less chance for copy-pasting mistakes)
on the other hand getting the KMS permissions and authenticating can be a hassle for the user: maybe copy pasting data from the KMS web UI would be overall easier for user?
Changes key loading helpers used by admin ceremony and metadata update commands to provide an option to the user to load a public key from HashiCorp Vault into TUF metadata.
TODO:
tuf-on-ci does the former (see "Prepare your local environment" in its docs/ONLINE-SIGNING-SETUP.md (cc @jku, who might be willing to share some wisdom )