You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Supported key types and signing scheme strings are currently hardcoded all over the library. We should define them in a single place e.g. securesystemslib.signer._constants and update all secureystemslib.signer.* modules to use them. (I suggest to not touch legacy modules such as secureystemslib.keys)
Publicly registered key types and schemes can be found in:
The 3 original key types are already defined as constants in init, which are only used in securesystemslib.interface. I suggest to deprecate them in favour of constants defined in the signer sub-package.
These feel a bit lost in the package-level namespace and are also
only a subset of the key types supported in the signer API.
Let's exclude them from the 1.0.0 API, and think of a suitable place
when addressing secure-systems-lab#593.
The patch also refactors an internal usage of one of the constants.
Externally, they seem to be only imported (but unused) in in-toto, which
is prepared for breaking changes in securesystemslib.
Signed-off-by: Lukas Puehringer <[email protected]>
Supported key types and signing scheme strings are currently hardcoded all over the library. We should define them in a single place e.g.
securesystemslib.signer._constants
and update allsecureystemslib.signer.*
modules to use them. (I suggest to not touch legacy modules such assecureystemslib.keys
)Publicly registered key types and schemes can be found in:
securesystemslib/securesystemslib/signer/__init__.py
Lines 39 to 55 in 135567f
Additionally, there are a few non-registered ones, which ca be found by looking for implementations of the
Key
interface.The text was updated successfully, but these errors were encountered: