rdimitrov / go-tuf-metadata Goto Github PK

Describe the bug

Currently a Refresh() can be done only once during the lifetime of an Updater.

This is not optimal for long-living processes so it would be better if we enable calling Refresh() more than once.

References:

• https://github.com/rdimitrov/go-tuf-metadata/blob/4e20edf17ab0b724127ca3d2374e5a9580f3b519/metadata/updater/updater.go#L98C1-L98C72

Reproduction steps

...

Expected behavior

Upon calling Refresh() make sure everything is up-to-date and if that's true:

• return nil, instead of an error (better imho)
  or
• return a custom error type so the user can check it via errors.Is (less favourite)

If something else occurred which failed us to refresh the metadata, still return the appropriate error value.

Additional context

No response

https://github.com/theupdateframework/taps/blob/master/tap15.md

There should be two PoCs created with go-tuf-metadata -

• One should be a direct replacement of go-tuf's usage with go-tuf-metadata.
• The second should be adding multi-repository support (TAP 4/TUF) for cosign which allows for creating a consensus for trusted roots when fetching the cosign keys for rekor, fulcio, etc.

Is your feature request related to a problem? Please describe.

From my brief reading of the metadata code, at present your library appears to make the same mistake as theupdateframework/go-tuf in that key signing is tighly coupled to primitive and crude on-disk keyfiles.

This means that real-world secure key storage such as PKCS#11 (theupdateframework/go-tuf#427), AWS KMS (theupdateframework/go-tuf#525) and others e.g. Yubikey are not readily supported and require hacky work-around kludges to work (e.g. manually hacking json files).

Describe the solution you'd like

Of course support for signing from local keyfiles stored on disk should remain, but integration with real world applications where the private key is stored in a non-exfilterable format should be supported.

Describe alternatives you've considered

No response

Additional context

No response

API to:

• load/unload private/public PEM formatted keys from file
• to/from crypto.PublicKey/crypto.PrivateKey
• from there on one can choose to further translate it to TUF Key type

References:

• https://github.com/sigstore/sigstore/blob/e2c1f8c3ccaf13f270430895a0142e58635eefad/pkg/cryptoutils/publickey.go
• https://github.com/sigstore/sigstore/blob/e2c1f8c3ccaf13f270430895a0142e58635eefad/pkg/cryptoutils/privatekey.go

Copied from the go-tuf project. This mostly applies to a repository-side CLI, which at the end should not be part of this project's scope.

As discussed in go-tuf, something like -

e.g. tuf-client list prints top-level targets
tuf-client list <delegation> prints targets for delegation

In the examples, we have to update the URL of the trusted sigstore-tuf-root GCS to the new CDN.

Currently, when constructing the URL of the target file we want to fetch we don't add the hash prefix to the target file name in case consistent snapshots is enabled, so we have to fix that.

Ref: https://theupdateframework.github.io/specification/latest/#fetch-target

Apparently codecov had an update and it started adding these file comments on a PR which are very distracting and make the review process difficult.

Let's disable this but still leave the codecov single comment in the PR showing the code coverage diff.

References:

• https://github.com/rdimitrov/go-tuf-metadata/pull/87/files
• https://github.com/rdimitrov/go-tuf-metadata/pull/87/checks?check_run_id=19375727202

Reference:

Is your feature request related to a problem? Please describe.

As of today we still pull in logrus inside library code which will then require every user of the library to pull in the same logger. This creates unnecessary dependencies for consumers of the library portion of this repo.

Describe the solution you'd like

Make logging optional for library code and/or remove the dependency on an external logger. The cleanest way would be to follow OpenTelemetrys strategy to use logr which is merely an interface for any supported logger that can be plugged into the codebase. It supports structured logging, loglevels and most importantly if no logger is supplied also supports a no-op fallback. This would also allow to continue using logrus for non-library code as logrus can be used with this interface. Work is also under way to support the new slog package of Go inside logr.

Describe alternatives you've considered

No response

Additional context

This issue was discussed prior on the CNCF Slack, the consensus was to make logging optional and more flexible as there is no hard dependency on logrus.

The issue is about ensuring go-tuf-metadata handles concurrency safely and can be used in such environments.

Motivated by sigstore/sigstore-go#41 (comment)

Reference - https://github.com/theupdateframework/taps/blob/master/tap4.md

Describe the bug

In part of the examples that we run in CI and tests too we use the jku/tuf-demo repository as something to run go-tuf-metadata against.

Recently tuf-demo switched to using tuf-on-ci and so we had to reset the repository along with its metadata and target files and thus why some of the examples/tests currently fail. For example, the succinct roles are not available so far in tuf-on-ci so we should update that part of the examples that we depending on such target file.

To fix this, we have to update the tests and the examples to search and fetch a target from the latest tuf-demo repository.

Reproduction steps

1. Run tests and examples
2. See them failing

Expected behavior

Tests and examples should not fail

Additional context

No response