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>
This vendors go-securesystemslib's dsse package in preparation for
adding support for DSSE signature extensions.
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>
Depending on the version, ssh-keygen might require both public and
private key file, for (passwordless) export (-e) and sign (-Y sign)
operations.
The function to load a public key from the unencrypted header of a private key
was only added recently, see
2b13d3934d
This commit makes sure that ssh tests always have access to public and
private key under the expected names: `<private>` and `<private>`.pub
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Follow Aditya's suggestion to "embed" all needed testfiles (ssh keys and
askpass script) as bytes and write them to a tmp dir where needed:
https://github.com/gittuf/gittuf/pull/414#discussion_r1618647676
Removes previously added testutils.go
**Interesting discovery**
In order to sign with an "rsa" key, ssh-keygen seems to expect an
"rsa.pub" in the same directory. This is not the case for encrypted rsa,
no for plaintext or encrypted ecdsa or ed25519.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Create "testutils" file in "common" package with test setup helper for
ssh keys and file copy helper.
- The ssh keys test setup function creates a test temp dir (for the
duration of the passed test), copies ssh keys from testdata and sets a
restrictive permission, as required by ssh-keygen.
- Kudos to @ivanayov, whose "copy" implementation in go-tuf I copied
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>
The original root and targets metadata schemas were taken directly from
the TUF specification. As such, they include fields that we don't use in
gittuf.
Removed Fields:
1. SpecVersion: this field identifies the version of the TUF
specification the metadata conforms to. We don't conform to the TUF
specification.
2. ConsistentSnapshot: this boolean field indicates if the repository
uses consistent snapshots as defined in the TUF specification. We
don't use this (and in fact we don't use snapshot metadata at all as
the RSL effectively serves the snapshot role).
3. Version: this field is an incrementing integer that identifies the
version of the metadata for the specific role. In TUF, this is used
to ensure we have a consistent set of metadata via the snapshot role.
As before, the RSL gives us this property naturally.
Note that we still don't use the Expires field in gittuf verification.
We need to explore what it means for policy metadata to expire in a Git
repository and whether the expiry check (for the latest policy metadata)
applies the same way it does in TUF.
Signed-off-by: Aditya Sirish <aditya@saky.in>
This commit introduces early, experimental support for gitsign
signatures on git commits. It uses TAP-18 to specify sigstore identity
constraints in delegations.
The feature introduced here depends on unreleased prototype code in
go-securesystemslib and is also insufficiently tested due to some
sigstore library constraints.
See: #73
Signed-off-by: Aditya Sirish <aditya@saky.in>
In some scenarios, keyIDs weren't automatically populated. This fixes
that and in doing so, modifies the ID() API to return an error.
Signed-off-by: Aditya Sirish <aditya@saky.in>
