This is a massive commit that isn't easy to split up, my apologies to
reviewers. Here's everything that's happening.
First, the base tuf package now includes interfaces for RootMetadata,
TargetsMetadata, Rule, and Principal. The first two are self-explanatory. Rule
represents some protection rule, currently matched by the Delegation schema,
while Principal defines a new take on who a trusted party is. Existing schemas
have been moved into a v01 subpackage. v01 also includes a Key type based on
signerverifier.SSLibKey which implements the Principal interface. This means
that expectations elsewhere (such as in repository and policy) re a principal
can be met by existing policy metadata.
Second, with most of the policy metadata manipulations having moved to the tuf
package, this commit drops them from the policy package as they were thin
wrappers. While we originally kept them around for the purposes of migrating
versions when a repository must move from the old metadata schema to a newer
one, it doesn't make sense to implement this in every individual manipulation
function.
Finally, the rest of the packages that handle keys (for adding to metadata or
for signing / verifying) have been updated to use either
signerverifier.SSLibKey directly or the new Principal interface, depending on
what the purpose is. For now, the idea is to continue using the
signerverifier.SSLibKey representation of a key itself for the signature
verification flows, though we may eventually move that into gittuf rather than
rely on go-securesystemslib. Note that some of the transitions have been
included in this commit for compatibility reasons, and subsequent PRs will
update that. For example, the GitHub app pull request approval attestation must
be updated to not use tufv01.Key objects to represent approvers.
Signed-off-by: Aditya Sirish A Yelgundhalli <ayelgundhall@bloomberg.net>
This commit drops support for the legacy / custom securesystemslib key format.
This format was used in two forms:
a) In tests
b) On disk in the policy state for the root keys
To address the removal, tests have been updated to use SSH keys (via the
ssh-keygen signer). This makes up the majority of the diff for this commit, and
includes some additions to the ssh package to more easily load test artifacts.
Additionally, we don't need to store a policy state's root keys on disk for
that ref. This was an error in our initial design, and it actually leads to
complications in ensuring that the policy state's on disk keys match the keys
listed in the state's root metadata. This commit updates it so only the root
metadata's record of the root keys are used, with the keys directory omitted
for future policy states. However, we maintain backwards compatibility for
policy states that include the keys on disk, we just ignore them.
Signed-off-by: Aditya Sirish A Yelgundhalli <ayelgundhall@bloomberg.net>
Previously, ssh Key satisfied both the dsse.Verifier interface and
served as TUF metadata key container. Unfortunately, it didn't seem
feasible to wire up the key container with the current TUF metadata
implementation, which uses SSlibKey.
This commit re-designs the ssh key implementation to use SSlibKey as key
container and a separate Verifier for verification.
See https://github.com/gittuf/gittuf/pull/429#issuecomment-2151588628
for more detailed design considerations.
Change details:
* Replace ssh Key with ssh Verifier, which satisfies the dsse.Verifier
interface, but is otherwise a black box (no key details exposed).
* Change NewKeyFromFile to return an SSlibKey, to be included in TUF
metadata.
* Add NewVerifierFromKey function to create an ssh Verifier from a
corresponding SSlibKey, e.g. included in TUF metadata, to verify
a signature from an ssh Signer.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
* A Key struct, similar to tuf.Key, to be included in TUF metadata (not
yet implemented), which implements the DSSE Verifier interface, to
verify signatures created with Signer.
* A Signer struct, which implements the DSSE Signer interface, to create
signatures using `ssh-keygen` and a path to a key.
* An Import function, to import a Key using `ssh-keygen` and a path to a
key.
For signing and Key import paths to either public or private, plaintext
or encrypted, rsa, ecdsa or ed25519 keys are supported (akin to git's
user.signingKey configuration).
Also adds basic smoke tests for the `ssh` package, and replaces updates
dsse tests to use this module.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
