When we drop support for our current bootstrap ceremony, signing and metadata update we will no longer use the old format of securesystemslib keys meaning we need to drop support for rstuf key generate as we don't want to confuse our users.
New keys can be generated with openssl and pypy/cryptography.
Have a look at this issue:
https://github.com/in-toto/in-toto/issues/662
I believe it's not worth it to update our current rstuf key generate as this will require future maintenance.
Same for rstuf key info: after we drop support for the old bootstrap ceremony, update and sign we will no longer need to manually describe keys with keyid, keytype and scheme. We will require users to load their public keys. Also, the current import of keys won't work with our new format and needs an update which I am not sure it makes sense to do.
Code of Conduct
[X] I agree to follow this project's Code of Conduct
What is the task about?
After @lukpueh refactoring in https://github.com/repository-service-tuf/repository-service-tuf-cli/pull/523 and all other related issues regarding improvements are resolved we need to discuss the future of the
rstuf key info
andrstuf key generate
commands.When we drop support for our current bootstrap ceremony, signing and metadata update we will no longer use the old format of
securesystemslib
keys meaning we need to drop support forrstuf key generate
as we don't want to confuse our users. New keys can be generated withopenssl
andpypy/cryptography
. Have a look at this issue: https://github.com/in-toto/in-toto/issues/662I believe it's not worth it to update our current
rstuf key generate
as this will require future maintenance.Same for
rstuf key info
: after we drop support for the old bootstrap ceremony, update and sign we will no longer need to manually describe keys withkeyid
,keytype
andscheme
. We will require users to load their public keys. Also, the current import of keys won't work with our new format and needs an update which I am not sure it makes sense to do.Code of Conduct