Move fulcioroots and pkg/cosign/tuf packages to sigstore/sigstore

[imjasonh]

trafficstars

Description

github.com/sigstore/cosign/cmd/cosign/cli/fulcio/fulcioroots contains methods to get x509.CertPools representing Fulcio's root and intermediates.

To do this, it calls initRoots, which based on the presence of a SIGSTORE_ROOT_FILE env var either loads those roots from that file or initializes a TUF client which pulls TUF config from a GCS bucket or HTTPS URL.

Based on my understanding of this code, I believe this could all move to sigstore/sigstore, and be reused by non-cosign clients (e.g., smimecosign) from there, instead of depending on the sigstore/cosign package.

Before I make any changes though, I wanted to check if this understanding is correct, and if folks think it's okay to move this to sigstore/sigstore (perhaps in pkg/fulcioroots and pkg/tuf)

The TUF client also carries a dependency on GCS client libraries, but I think that could also be dropped since it only makes unauthenticated requests, which can also be made to, e.g., https://[bucket].storage.googleapis.com/[object] unless I'm mistaken.

@haydentherapper @znewman01 I think you might have insights?

[haydentherapper]

cc @asraa about TUF

There's so much we should move to sigstore/sigstore. The TUF client should be moved too at some point. I'm fine with having this moved out to sigstore/sigstore. Will SIGSTORE_ROOT_FILE stay in Cosign? I assume we don't want to define CLI flags in sigstore/sigstore.

Agreed about GCS, the objects can be accessed using a REST API.

[imjasonh]

Will SIGSTORE_ROOT_FILE stay in Cosign?

I don't know enough about the use case to comment. I don't think I'd mind as a prospective consumer of the package that its behavior was dependent on an env var, especially if that was named like SIGSTORE_ and not COSIGN_.

I'll start moving stuff and see if I can send some PRs. Thanks!

[znewman01]

Overall 👍

Agreed about GCS, the objects can be accessed using a REST API.

We don't need to solve this now (I'm happy to just make HTTP requests) but is there a way we would be able to keep the GCS client library in an analogous situation? Maybe dependency-inject the TUF remote store and just pull in packages containing the ones you need?

I don't think I'd mind as a prospective consumer of the package that its behavior was dependent on an env var, especially if that was named like SIGSTORE_ and not COSIGN_.

I would TBH, I think overall burying config options deep in some automagic code that's tough to modify as a caller without setting an env var is bad for testability etc. Further, if I'm using sigstore as a client but I want my own TUF state it'd possible that I wouldn't want to respect that variable. Maybe if there was a Sigstore-TUF client struct that had this configurable, and it had a default constructor that pulled from an environment variable?

And while I'm being cranky, I already think this is misbehaved because it doesn't respect XDG_STATE_HOME too.l

[haydentherapper]

Maybe if there was a Sigstore-TUF client struct that had this configurable, and it had a default constructor that pulled from an environment variable?

+1, that's how I'd prefer this be set up too.

Can you chime in on https://github.com/sigstore/sigstore/issues/436?