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>
The old methods are replaced by a simpler CanSign method needed in cmd as a
pre-run check.
Signed-off-by: Aditya Sirish A Yelgundhalli <ayelgundhall@bloomberg.net>
- Added the expectedRootKeys flag to clone.go
- Added addtional test in sync_test.go for expectedRootKeys
Signed-off-by: neilnaveen <42328488+neilnaveen@users.noreply.github.com>
This commit has gittuf check if signing using the user's
signing key (specified in the git configuration) is possible
for commands that require this. This is done by way of a
function in cmd/common/common.go, called in commands' PreRunE.
Signed-off-by: Pat Zielinski <70954403+patzielinski@users.noreply.github.com>
The CLI package checks if gittuf is in eval mode before invoking
functions that are not meant for regular use. This commit also adds the
gated invocation for the first eval function, the ability to record an
RSL entry for non-latest commits in a ref.
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>
