Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fetch verification targets by TUF custom metadata #1423

Merged
merged 3 commits into from
Feb 11, 2022

Conversation

haydentherapper
Copy link
Contributor

Summary

Continuing #1273, this adds support for fetching a list of TUF targets by custom metadata. This will be used for verification using expired/rotated targets. All targets will be persisted in the TUF target metadata. Only one will be marked as active while the others are marked as expired.

The custom metadata on a target looks like looks like:

      "fulcio.crt.pem": {
        "custom": {
          "sigstore": {
            "status": "Active",
            "usage": "Fulcio"
          }
        },
        "hashes": {
          "sha512": "f2e33a6dc208cee1f51d33bbea675ab0f0ced269617497985f9a0680689ee7073e4b6f8fef64c91bda590d30c129b3070dddce824c05bc165ac9802f0705cab6"
        },
        "length": 740
      },

Possible statuses are active or expired, and possible usages are fulcio, rekor, and ctfe. unknown is also supported for each as a default value.

To test this, I:

  • Used the current TUF targets to sign and verify. These TUF targets do not contain custom metadata, so this tested the fallback.
  • Initialized a TUF repository with custom metadata for each target (based on the script from the BYO TUF blog post). I changed the filenames too so no fallback would happen. Initialized Cosign with the custom TUF metadata. Successfully signed and verified.

Next steps:

  • Use the Status of the custom metadata to inform users when verifying with an expired target
  • Remove the OCI timestamp code
  • After TUF Root v3 is published and bundled with Cosign, we can remove the code that falls back to targets by filename.

Ticket Link

Fixes #1342

Ref #1273

Release Note

TUF targets can now be referenced by custom metadata instead of filename

Multiple verification keys can be used to verify Fulcio certificates, Rekor entries, or Fulcio CT log SCTs

@haydentherapper
Copy link
Contributor Author

cc @asraa @dlorenc @bobcallaway

@dlorenc
Copy link
Member

dlorenc commented Feb 8, 2022

These test failures look related to the PR, any idea?

@haydentherapper
Copy link
Contributor Author

Reran tests, the unit tests succeeded (I saw the flaky "timestamp.json" off by two bytes), but the KinD e2e tests are failing. Investigating now

@haydentherapper
Copy link
Contributor Author

It appears the tests collided with an ongoing distroless release. It pulled the latest image before signing was complete. No more errors!

@dlorenc
Copy link
Member

dlorenc commented Feb 10, 2022

Cc @znewman01 could you take a look?

@znewman01
Copy link
Contributor

could you take a look?

Yup, sometime in the next couple hours.

pkg/cosign/tuf/client.go Show resolved Hide resolved
pkg/cosign/tuf/client.go Outdated Show resolved Hide resolved
pkg/cosign/tuf/client.go Outdated Show resolved Hide resolved
pkg/cosign/tuf/client.go Show resolved Hide resolved
Copy link
Contributor

@znewman01 znewman01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM


import "testing"

func TestGetFulcioRoots(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pardon my unfamiliarity with the codebase here.

I don't really understand this test -- we make a TUF client using tuf.NewFromEnv() which AFAICT looks in ~/.sigstore/root by default. Is there some test fixture that sets TUF up for us?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're correct, this just ends up relying on the embedded root. I want to refactor the tests in a later PR to use the test utility newTufCustomRepo or newTufRepo so we can generate an instance of the TUF repository that we can easily manipulate to test different edge cases. For now, this test just aims to increase code coverage and exercise Get.

pkg/cosign/tuf/client.go Show resolved Hide resolved
t.Error(err)
}
if l := dirLen(t, tufRoot); l == 0 {
t.Errorf("expected filesystem writes, got %d entries", l)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little puzzled by "expected filesystem writes". Can you clarify?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a check to make sure Initialize wrote something to the tufRoot directory.

pkg/cosign/tuf/client_test.go Show resolved Hide resolved
cmd/cosign/cli/fulcio/fulcioverifier/fulcioverifier.go Outdated Show resolved Hide resolved
if err != nil {
return err
}
// Is there a reason why this must be ECDSA key?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there? :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code makes assumptions about all of the TUF targets. We should clearly document these assumptions in cosign/root-signing. We could add support for other keys if there was a need, and it might come up with BYO-TUF. I'd encourage others to use ECDSA, primarily because you can have much smaller keys and get the same security strength.

pkg/cosign/tuf/client_test.go Outdated Show resolved Hide resolved
Copy link
Contributor Author

@haydentherapper haydentherapper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review!


import "testing"

func TestGetFulcioRoots(t *testing.T) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're correct, this just ends up relying on the embedded root. I want to refactor the tests in a later PR to use the test utility newTufCustomRepo or newTufRepo so we can generate an instance of the TUF repository that we can easily manipulate to test different edge cases. For now, this test just aims to increase code coverage and exercise Get.

if err != nil {
return err
}
// Is there a reason why this must be ECDSA key?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code makes assumptions about all of the TUF targets. We should clearly document these assumptions in cosign/root-signing. We could add support for other keys if there was a need, and it might come up with BYO-TUF. I'd encourage others to use ECDSA, primarily because you can have much smaller keys and get the same security strength.

pkg/cosign/tuf/client_test.go Show resolved Hide resolved
t.Error(err)
}
if l := dirLen(t, tufRoot); l == 0 {
t.Errorf("expected filesystem writes, got %d entries", l)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a check to make sure Initialize wrote something to the tufRoot directory.

pkg/cosign/tuf/client_test.go Outdated Show resolved Hide resolved
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
This uses GetTargetsByMeta to read the targets
using the custom metadata, or fallback to the old
targets by filename.

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
@dlorenc dlorenc merged commit 0e76059 into sigstore:main Feb 11, 2022
@github-actions github-actions bot added this to the v1.6.0 milestone Feb 11, 2022
hatmarch pushed a commit to hatmarch/cosign that referenced this pull request Apr 19, 2022
* Add TUF client method for fetching by metadata

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>

* Fetch verification targets by TUF custom metadata

This uses GetTargetsByMeta to read the targets
using the custom metadata, or fallback to the old
targets by filename.

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>

* Resolve PR comments, linter, and update tests

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
mlieberman85 pushed a commit to mlieberman85/cosign that referenced this pull request May 6, 2022
* Add TUF client method for fetching by metadata

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>

* Fetch verification targets by TUF custom metadata

This uses GetTargetsByMeta to read the targets
using the custom metadata, or fallback to the old
targets by filename.

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>

* Resolve PR comments, linter, and update tests

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TUF: Use custom metadata to identify TUF target usage
4 participants