Add replacement API for '*keys' and 'interface' key generation and import #604

lukpueh · 2023-06-26T15:39:00Z

Notes to reviewers

Maybe closes Design key import/generation for the signer API #466.
Includes commits from signer: refactor SSlibSigner #590, which can be ignored when reviewing here.
Is well-suited for a commit-by-commit review.
If desired, I can create separate smaller PRs.
At this point, I'd mostly like comments about whether this proposals seems fit to replace the related legacy "API".

Background / Motivation

My initial plan was to refactor key generation, export and import implementation in *keys modules, akin to signature creation (#590) and verification (#585), with the goals to

reduce and modernize implementation code
remove obsolete internal (schema/formats, etc.) and external (pynacl) dependencies
preserve support for legacy on-disk key formats via interface (keygen, import, export) and SSlibSigner (sign)

Unfortunately, I couldn't find a similarly non-invasive and future-proof way, as with the signing/verifying refactors. The reason for this seems to be that on-disk key formats for public keys, and for encrypted and non-encyrypted private keys, their in-memory representation, and the public key container format and public key data format, as they are listed in tuf/in-toto metadata, are all extremely and inconsistently coupled via a loosely defined keydict.

Re-writing large portions of legacy code, just to support inconsistent, proprietary on-disk key formats, didn't seem worth the effort. Instead, I added a non-backwards-compatible but modern and light-weight replacement API, which supports old and new securesystemslib usage paradigms for the known key types.

IMPORT NOTE: Public key metadata formats as used in TUF and in-toto metadata are not changed and remain backwards compatible.

Description of changes

Add methods for ketypes rsa, ecdsa and ed25519 to:

generate new key pair as Signer instance
for simple in-memory setups, tests or demos
import public key from standard PEM/subjectPublicKeyInfo encoded file as Key instance
for simple setups, tests and demos, which use stand-alone key files
import encrypted or non-encrypted private key from standard PEM/PKCS8 encoded file as Signer instance
for simple setups, tests and demos, which use stand-alone key file; but also compatible with new usage-paradigm, with signer uri

Missing features compared to legacy API

Generate and write key pairs
Import key files from proprietary legacy formats
Import private key without already having the public key
Import signer from envvar

Future work / TODO (not necessarily in this PR)

Polish implementation: I think, the API design is right and complete, but internally we could do some deduplication and polishing (e.g. keytype/scheme switches)
Use constants instead of hard-coded keytype/scheme strings and lists (signer: add constants for key types and signing schemes #593)
Review interface boundaries between CryptoSigner and SSlibKey (e.g. CrytpoSigner instances require an SSlibKey, but not all SSlibKey schemes are supported by all signers)
Review validation, e.g. do we fail on
- incorrect scheme/type for signer?
- incorrect private key for signer?
- incorrect public key values for scheme/type?
- missing optional dependency (UnsupportedLibraryError) in all public methods?
More tests

lukpueh · 2023-06-27T13:14:08Z

Some additional comments wrt:

Missing features compared to legacy API

Generate and write key pairs

Now that file-import works with standard formats, users can easily use 3rd-party tools for this. I suggest to just add e.g. the openssl commands, which I used to generate test key files (see related commit message), to the docs.

If there's a need, we can easily add the feature. It's just a few lines of pyca/cryptography code).

Import key files from proprietary legacy formats

Let's just not support this in new API. Instead, I suggest to offer migration support when releasing a version without the legacy interfaces.

Import private key without already having the public key

Import signer from envvar

Same as for generate and write, if there's a need for these features we can easily add them.

Add optional signer (Signer) arg to runlib's run/record methods, as alternative way of signing the resulting link metadata, instead of using signing_key, gpg_keyid, or use_default_gpg. In the case of in_toto_record_stop, the public_key (Key) field of the signer, is used to verify the preliminary link metadata file. This field is not yet part of the interface, but all currently implemented signers have it. This is part of removing securesystemslib legacy interfaces, see secure-systems-lab/securesystemslib#604 TODO (this PR) - add tests for signer arg TODO (maybe this PR) - add deprecation warning for legacy key args and legacy gpg formats (only show on API use, not on CLI use!) TODO (follow-up) - add Metadata.verify(public_key: Key), if necessary (maybe we can just do this in runlib/verifylib), and use in in_toto_record_stop instead of passing `signer.public_key.to_dict()` to `Metadata.verify_signature(...)` Signed-off-by: Lukas Puehringer <[email protected]>

IMPORTANT: Requires unlreleased securesystemslib code from secure-systems-lab/securesystemslib#590 Adds optional signer (Signer) arg to runlib's run/record functions, as alternative way of signing resulting link metadata, instead of using signing_key, gpg_keyid, or use_default_gpg. Closes in-toto#532 **Addtional notes:** In in_toto_record_stop, the public_key (Key) field of the signer is used to verify the preliminary link metadata file. The field is not yet part of the interface, although all signer implementations in secureystemslib have it: secure-systems-lab/securesystemslib#605 The patch aims to be minimally invasive, and thus barely refactors any of the existing signing argument handling in the relevant functions. Although, it was tempting to simplify the code, it turned out harder than thought, and therefor not worth the effort, given that these arguments are bound to deprecation. This is patch is part of a series of patches to prepare for the planned removal of securesystemslib legacy interfaces, see secure-systems-lab/securesystemslib#604 for details. **TODO (follow-up)** - add deprecation warning for legacy key args and legacy gpg formats (only show on API use, not on CLI use!) - add Metadata.verify(public_key: Key), if necessary (maybe we can just do this in runlib/verifylib), and use in in_toto_record_stop instead of passing `signer.public_key.to_dict()` to `Metadata.verify_signature(...)` - prepare for ssslib legacy interface removal in other parts of in_toto: - in-toto-run, in-toto-record (in-toto#533) - verifylib / in-toto-verify - in-toto-sign - Metadata API / docs - ... Signed-off-by: Lukas Puehringer <[email protected]>

jku

I think this is close... Left a few comments while reading, but the core issue I have is that the Signer class hierarchy is now quite complicated, the hierarchy is largely public, and it's unclear (to me) what classes the caller should be using in different situations. In other words: why is this class public, what is its purpose for the user. This could just boil down to me not understanding the use cases these are for -- each public class could document when it should be instantiated and how.

I also understand that not everything is implemented... but fixing that is hard if it's not clear what needs to be implemented

I guess the use cases where we should be able to point to a specific class and method are

How do I construct a signer when I need to sign? (I assume the answer is still Signer.from_private_key_uri() should be used, and SIGNER_FROM_URI_SCHEME can be used to configure the implementations used in the application)
How do I construct a private key uri and Key for storing for later use when using cryptography (assume we have bytes we need from cryptography) -- equivalent of import_() in other Signers. A complete example would help
generating a new private and public key for storing a private key uri, private key and public key (I'd really like to leave this to user calling cryptography and giving us bytes, but... I suppose we need to support it. I'm less sure if the classes need to be public or ig these are just public helper methods -- does showing the class to user give some value?)

TL;DR: I think it's close but I still don't quite get it, we should probably chat and maybe I'll figure it out...

jku · 2023-08-07T09:40:41Z

securesystemslib/signer/_key.py

+        # FIXME: Sounds like it's an SSlibKey factory, but isn't. Should think
+        of a better name or refactor _verify!


yeah, it's not "from pem" it's more like _crypto_key() (for consistency with the method below)

Could file an issue instead of fixing here

securesystemslib/signer/_key.py

securesystemslib/signer/_signer.py

This patch refactors the SSlibSigner signing implementation, akin to secure-systems-lab#585, which refactored signature verification (see PR for details about legacy code and rationale). Unlike, secure-systems-lab#585 this patch does not only condense and move the code for singing, but creates a new hierarchy of signers to achieve two additional goals: 1. Provide tiny rsa, ecdsa and ed25519 pyca/cryptography Signer implementations, which are independent of private key serialization formats, above all, of the proprietary legacy keydict format. This is particularly interesting, when refactoring existing or designing new key generation or import interfaces, where it would be annoying to move back and forth over the legacy keydict. 2. Preserve SSlibSigner including its internal legacy keydict data structure. SSlibSigner is and remains a backwards-compatibility crutch. Breaking its existing users to make it a little less awkward would defeat that purpose. And even though the Signer API doc says that the internal data structure is not part of the public API, users may rely on it (python-tuf actually does so at least in tests and demos). To achieve these goals, SSlibSigner becomes a container for the newly added CryptoSigner class, whose implementations can also be used as independent Signers, and above all created or imported, with very few lines of pyca/cryptography code. **Caveat:** Latest python-tuf tests pass against this patch, except for one, which expects a keydict deserialization failure in `sign`, which now happens in `__init__` initialization time. This seems feasible to fix in python-tuf. Also note that private key format errors are now ValueErrors and no longer unreliably either FormatErrors or sometimes UnsupportedAlgorithmErrors. **Future work (will ticketize):** - Signing schemes strings should not be hardcoded all over the place but defined once in constants for all of securesystemslib. - There is some duplicate code for scheme string dissection and algorithm selection, which could be unified for all signers and public keys. - (bonus) secure-systems-lab#585 considered creating separate RSAKey, ECDSAKey, ED25519Key classes, but ended up putting everything into SSlibKey. Now that we have separate signers for each of these key types, which have a field for the corresponding public key object, it might make sense to reconsider this separation. This would give us a more robust data model, where e.g. allowed signing schemes are only validated once in the public key constructor and are thus validated implicitly in the signer constructor. Signed-off-by: Lukas Puehringer <[email protected]>

Also moves error tests to separate function. Signed-off-by: Lukas Puehringer <[email protected]>

Default keyid computation is non-public functionality, which is currently used in Signer methods only, but will also be used in Key methods in the future. To avoid circular imports and protected-access, the method is moved to an internal signer-specific utils module. Signed-off-by: Lukas Puehringer <[email protected]>

Signed-off-by: Lukas Puehringer <[email protected]>

Add test keys for all three 'sslib' keytypes, using standard encoding and format: - PEM/PKCS8 for private keys, and - PEM/PKCS8 for encrypted private keys, and - PEM/subjectPublicKeyInfo for public keys. These are the PEM formats recommended and supported by pyca/cryptography. All keys were created with 'openssl' (LibreSSL 3.3.6 for rsa and ecdsa; and OpenSSL 3.1.1 for ed25519): ``` # RSA openssl genpkey -algorithm rsa \ -out rsa_private.pem openssl pkcs8 -in rsa_private.pem -topk8 -passout pass:hunter2 \ -out rsa_private_encrypted.pem openssl rsa -in rsa_private.pem -pubout \ -out rsa_public.pem # ECDSA (NIST P-256) openssl genpkey -algorithm EC \ -pkeyopt ec_paramgen_curve:P-256 \ -pkeyopt ec_param_enc:named_curve \ -out ecdsa_private.pem openssl pkcs8 -in ecdsa_private.pem -topk8 -passout pass:hunter2 \ -out ecdsa_private_encrypted.pem openssl pkey -in ecdsa_private.pem -pubout \ -out ecdsa_public.pem # Ed25519 openssl genpkey -algorithm Ed25519 \ -out ed25519_private.pem openssl pkcs8 -in ed25519_private.pem -topk8 -passout pass:hunter2 \ -out ed25519_private_encrypted.pem openssl pkey -in ed25519_private.pem -pubout \ -out ed25519_public.pem ``` Signed-off-by: Lukas Puehringer <[email protected]>

Add method to import public key files from a standard PEM/subjectPublicKeyInfo encoding for all three sslib keytypes. Note that other PEM formats might work but aren't tested. Signed-off-by: Lukas Puehringer <[email protected]>

Port SSlibSigner.from_priv_key_uri to CryptoSigner to load private key files from standard formats. But don't register yet in SIGNER_FOR_URI_SCHEME. DOES NOT support: - legacy proprietary key formats and custom decryption, - envvar reading DOES support: - encrypted and non-encrypted PEM/PKCS8 format for all three sslib keytypes Note that other PEM formats might work but aren't tested. Signed-off-by: Lukas Puehringer <[email protected]>

Add generate methods to RSASigner, ECDSASigner and Ed25519Signer classes, to generate key pairs (or rather Signer with attached public key) for quick in-memory signing and verifying, e.g. for tests or demos. Signed-off-by: Lukas Puehringer <[email protected]>

CryptoSigner.from_priv_key_uri was copied from SSlibSigner. This commit changes to return type and error message from SSlibSigner to CryptoSigner. Signed-off-by: Lukas Puehringer <[email protected]>

Move SSlibSigner and CryptoSigner to separate internal modules for a cleaner code separation of signer interface and implementations. This commit does not change functionality. SSlibSigner and CryptoSigner (and its subclasses) remain publicly accessible via `securesystemslib.signer`. Signed-off-by: Lukas Puehringer <[email protected]>

Move functions from subclasses to superclass: Ed25519Signer.generate() -> CryptoSigner.generate_ed25519() RSASigner.generate() -> CryptoSigner.generate_rsa() ECDSASigner.generate() -> CryptoSigner.generate_ecdsa() This allows us to make the subclasses non-public. Signed-off-by: Lukas Puehringer <[email protected]>

To decrease the API surface, RSASigner, Ed25519Signer and ECDSASigner are made non-public and should be loaded via Signer.from_priv_key_uri, or generated via CryptoSigner.generate_* methods. NOTE: Removing them from securesystemslib.signer.__init__ would be enough (they are already in an internal module), but prefixing the classes with an underscore makes it more explicit to us securesystemslib developers. Signed-off-by: Lukas Puehringer <[email protected]>

If needed we can add a from_file wrapper on top of from_pem (bytes). Signed-off-by: Lukas Puehringer <[email protected]>

Signed-off-by: Lukas Puehringer <[email protected]>

- update SSlibKey import - use new compute_default_keyid Signed-off-by: Lukas Puehringer <[email protected]>

lukpueh · 2023-08-10T13:59:32Z

@jku, I just pushed the changes we discussed (see 7 most recent commits). The POC/documentation you asked for is in CRYPTO_SIGNER.md. I think this works as is, without any additional API. And even if not, and we can easily add. e.g. import_ methods later.

Let me know, if you think this is the right path forward and/or if you want me to break this up into smaller more manageable PRs.

jku

Yeah this looks good to me. Would love to have some other peoples opinions but I'm happy with this.

Left a question on updating the default signer lookup table

jku · 2023-08-11T09:28:19Z

securesystemslib/signer/__init__.py

 )
 from securesystemslib.signer._sigstore_signer import SigstoreKey, SigstoreSigner
 from securesystemslib.signer._spx_signer import (
    SpxKey,
    SpxSigner,
    generate_spx_key_pair,
 )
+from securesystemslib.signer._sslib_signer import SSlibSigner

 # Register supported private key uri schemes and the Signers implementing them
 SIGNER_FOR_URI_SCHEME.update(


Should we change the default handler for FILE_URI_SCHEME? (and maybe leave a comment that ENVVAR_URI_SCHEME is deprecated unless someone reimplements it)

Adds optional signer (Signer) arg to runlib's run/record functions, as alternative way of signing resulting link metadata, instead of using signing_key, gpg_keyid, or use_default_gpg. Closes in-toto#532 **Addtional notes:** In in_toto_record_stop, the public_key (Key) field of the signer is used to verify the preliminary link metadata file. The field is not yet part of the interface, although all signer implementations in secureystemslib have it: secure-systems-lab/securesystemslib#605 The patch aims to be minimally invasive, and thus barely refactors any of the existing signing argument handling in the relevant functions. Although, it was tempting to simplify the code, it turned out harder than thought, and therefor not worth the effort, given that these arguments are bound to deprecation. This patch is part of a series of patches to prepare for the planned removal of securesystemslib legacy interfaces, see secure-systems-lab/securesystemslib#604 for details. **TODO (follow-up)** - add deprecation warning for legacy key args and legacy gpg formats (only show on API use, not on CLI use!) - add Metadata.verify(public_key: Key), if necessary (maybe we can just do this in runlib/verifylib), and use in in_toto_record_stop instead of passing `signer.public_key.to_dict()` to `Metadata.verify_signature(...)` - prepare for ssslib legacy interface removal in other parts of in_toto: - in-toto-run, in-toto-record (in-toto#533) - verifylib / in-toto-verify - in-toto-sign - Metadata API / docs - ... Signed-off-by: Lukas Puehringer <[email protected]>

Upstream CryptoSigner may or may not provide API for this at some point (see secure-systems-lab/securesystemslib#664). If not, it should at least allow us to implement it ourselves without access to protected names (see TODO comments). Commit includes basic tests to load from un/encrypted pems. Test pems come from secure-systems-lab/securesystemslib#604. Encryption pw is hunter2. Signed-off-by: Lukas Puehringer <[email protected]>

blocks on: - in-toto#649, and - secure-systems-lab/securesystemslib#678 + release --- This is meant as replacement for `--layout-keys`, supporting a consistent standard key file format (subjectPublicKeyInfo/pem). It is part of a series of patches to prepare for deprecation of legacy securesystemslib interfaces and key file formats. **Change details** Adds helper to load public key file as SSlibKey and uses it in in-toto-verify for keys passed with --subjectPublicKeyInfo. NOTE: uses unreleased securesystemslib API, which **blocks** this PR. SSlibKey is converted to its dictionary representation with the keyid included, to make it compatible with verifylib.in_toto_verify. In the future we might want to support Key (SSlibKey's base class) natively in in_toto_verify. This PR also adds a deprecation warning for --layout-keys and tests using the demo supply chain. Test public key files come from secure-systems-lab/securesystemslib#604. Signed-off-by: Lukas Puehringer <[email protected]>

Upstream CryptoSigner may or may not provide API for this at some point (see secure-systems-lab/securesystemslib#664). If not, it should at least allow us to implement it ourselves without access to protected names (see TODO comments). Commit includes basic tests to load from un/encrypted pems. Test pems come from secure-systems-lab/securesystemslib#604. Encryption pw is hunter2. Signed-off-by: Lukas Puehringer <[email protected]>

blocks on: - in-toto#649, and - secure-systems-lab/securesystemslib#678 + release --- This is meant as replacement for `--layout-keys`, supporting a consistent standard key file format (subjectPublicKeyInfo/pem). It is part of a series of patches to prepare for deprecation of legacy securesystemslib interfaces and key file formats. **Change details** Adds helper to load public key file as SSlibKey and uses it in in-toto-verify for keys passed with --subjectPublicKeyInfo. NOTE: uses unreleased securesystemslib API, which **blocks** this PR. SSlibKey is converted to its dictionary representation with the keyid included, to make it compatible with verifylib.in_toto_verify. In the future we might want to support Key (SSlibKey's base class) natively in in_toto_verify. This PR also adds a deprecation warning for --layout-keys and tests using the demo supply chain. Test public key files come from secure-systems-lab/securesystemslib#604. Signed-off-by: Lukas Puehringer <[email protected]>

blocks on: - in-toto#649, and - secure-systems-lab/securesystemslib#678 + release --- This is meant as replacement for `--layout-keys`, supporting a consistent standard key file format (subjectPublicKeyInfo/pem). It is part of a series of patches to prepare for deprecation of legacy securesystemslib interfaces and key file formats. **Change details** Adds helper to load public key file as SSlibKey and convert it to its dictionary representation with the keyid included, to make it compatible with verifylib.in_toto_verify. in-toto-verify uses this for keys passed with --subjectPublicKeyInfo. NOTE: requires unreleased securesystemslib API, which **blocks** this PR. In the future we might want to support Key (SSlibKey's base class) natively in in_toto_verify. This PR also adds a deprecation warning for --layout-keys and tests using the demo supply chain. Test public key files come from secure-systems-lab/securesystemslib#604. Signed-off-by: Lukas Puehringer <[email protected]>

Upstream CryptoSigner may or may not provide API for this at some point (see secure-systems-lab/securesystemslib#664). If not, it should at least allow us to implement it ourselves without access to protected names (see TODO comments). Commit includes basic tests to load from un/encrypted pems. Test pems come from secure-systems-lab/securesystemslib#604. Encryption pw is hunter2. Signed-off-by: Lukas Puehringer <[email protected]>

blocks on: - in-toto#649 --- This is meant as replacement for `--layout-keys`, supporting a consistent standard key file format (subjectPublicKeyInfo/pem). It is part of a series of patches to prepare for deprecation of legacy securesystemslib interfaces and key file formats. **Change details** Adds helper to load public key file as SSlibKey and convert it to its dictionary representation with the keyid included, to make it compatible with verifylib.in_toto_verify. in-toto-verify uses this for keys passed with --subjectPublicKeyInfo. NOTE: requires unreleased securesystemslib API, which **blocks** this PR. In the future we might want to support Key (SSlibKey's base class) natively in in_toto_verify. This PR also adds a deprecation warning for --layout-keys and tests using the demo supply chain. Test public key files come from secure-systems-lab/securesystemslib#604. Signed-off-by: Lukas Puehringer <[email protected]>

Upstream CryptoSigner may or may not provide API for this at some point (see secure-systems-lab/securesystemslib#664). If not, it should at least allow us to implement it ourselves without access to protected names (see TODO comments). Commit includes basic tests to load from un/encrypted pems. Test pems come from secure-systems-lab/securesystemslib#604. Encryption pw is hunter2. Signed-off-by: Lukas Puehringer <[email protected]>

blocks on: - in-toto#649 --- This is meant as replacement for `--layout-keys`, supporting a consistent standard key file format (subjectPublicKeyInfo/pem). It is part of a series of patches to prepare for deprecation of legacy securesystemslib interfaces and key file formats. **Change details** Adds helper to load public key file as SSlibKey and convert it to its dictionary representation with the keyid included, to make it compatible with verifylib.in_toto_verify. in-toto-verify uses this for keys passed with --subjectPublicKeyInfo. NOTE: requires unreleased securesystemslib API, which **blocks** this PR. In the future we might want to support Key (SSlibKey's base class) natively in in_toto_verify. This PR also adds a deprecation warning for --layout-keys and tests using the demo supply chain. Test public key files come from secure-systems-lab/securesystemslib#604. Signed-off-by: Lukas Puehringer <[email protected]>

lukpueh requested a review from jku June 29, 2023 09:25

lukpueh mentioned this pull request Jun 29, 2023

Task: Add distributed async (metadata sign) and include support to ceremony repository-service-tuf/repository-service-tuf-cli#294

Closed

1 task

lukpueh mentioned this pull request Jul 4, 2023

signer API: add public key attribute to Signer interface #605

Closed

lukpueh mentioned this pull request Jul 4, 2023

runlib: add signer kwarg to run and record methods in-toto/in-toto#612

Merged

lukpueh mentioned this pull request Jul 17, 2023

signer: refactor SSlibSigner #590

Closed

jku reviewed Aug 7, 2023

View reviewed changes

lukpueh added 16 commits August 10, 2023 15:42

test: test SSlibSigner with all supported schemes

7b5a13a

Also moves error tests to separate function. Signed-off-by: Lukas Puehringer <[email protected]>

key: add 'FIXME' comment for bad method name

0c54aa7

Signed-off-by: Lukas Puehringer <[email protected]>

key: add public key file import method

7dbbb2e

Add method to import public key files from a standard PEM/subjectPublicKeyInfo encoding for all three sslib keytypes. Note that other PEM formats might work but aren't tested. Signed-off-by: Lukas Puehringer <[email protected]>

signer: fix copy/paste mistake in CryptoSigner

16e48dd

CryptoSigner.from_priv_key_uri was copied from SSlibSigner. This commit changes to return type and error message from SSlibSigner to CryptoSigner. Signed-off-by: Lukas Puehringer <[email protected]>

key: SSlibKey.from_file -> SSlibKey.from_pem

414460f

If needed we can add a from_file wrapper on top of from_pem (bytes). Signed-off-by: Lukas Puehringer <[email protected]>

docs: add CryptoSigner usage documentation

f021d8b

Signed-off-by: Lukas Puehringer <[email protected]>

signer: deprecate SSlibSigner and sslib keydict

9ddde6d

Signed-off-by: Lukas Puehringer <[email protected]>

signer: fix rebase issues in aws_signer

3951fed

- update SSlibKey import - use new compute_default_keyid Signed-off-by: Lukas Puehringer <[email protected]>

lukpueh force-pushed the crypto-signer-keygen-and-import branch from b4cf6a1 to 3951fed Compare August 10, 2023 13:49

lukpueh requested a review from jku August 11, 2023 08:18

jku approved these changes Aug 11, 2023

View reviewed changes

lukpueh marked this pull request as ready for review August 11, 2023 11:39

This was referenced Aug 11, 2023

key: rename SSlibKey._from_pem method #615

Closed

key: consider making SSlibKey._from_crypto_public_key public API #616

Closed

signer: Improved the "file-based signer" #617

Closed

lukpueh merged commit 5c6d0be into secure-systems-lab:main Aug 11, 2023

lukpueh mentioned this pull request Aug 21, 2023

Automate Signer API docs for RTD #622

Merged

MVrachev mentioned this pull request Aug 30, 2023

Release v0.29.0 #631

Closed

jku mentioned this pull request Sep 1, 2023

Create Example app #633

Open

lukpueh mentioned this pull request Nov 23, 2023

Add --verification-keys (subjectPublicKeyInfo) arg to in-toto-verify in-toto/in-toto#652

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add replacement API for '*keys' and 'interface' key generation and import #604

Add replacement API for '*keys' and 'interface' key generation and import #604

lukpueh commented Jun 26, 2023 •

edited

Loading

lukpueh commented Jun 27, 2023

jku left a comment

jku Aug 7, 2023

lukpueh commented Aug 10, 2023

jku left a comment

jku Aug 11, 2023

		# FIXME: Sounds like it's an SSlibKey factory, but isn't. Should think
		of a better name or refactor _verify!

Add replacement API for '*keys' and 'interface' key generation and import #604

Add replacement API for '*keys' and 'interface' key generation and import #604

Conversation

lukpueh commented Jun 26, 2023 • edited Loading

lukpueh commented Jun 27, 2023

jku left a comment

Choose a reason for hiding this comment

jku Aug 7, 2023

Choose a reason for hiding this comment

lukpueh commented Aug 10, 2023

jku left a comment

Choose a reason for hiding this comment

jku Aug 11, 2023

Choose a reason for hiding this comment

lukpueh commented Jun 26, 2023 •

edited

Loading