-
Notifications
You must be signed in to change notification settings - Fork 551
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
Move fulcioroots and pkg/cosign/tuf packages to sigstore/sigstore #1865
Comments
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 Agreed about GCS, the objects can be accessed using a REST API. |
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 I'll start moving stuff and see if I can send some PRs. Thanks! |
Overall 👍
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 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 |
+1, that's how I'd prefer this be set up too. Can you chime in on sigstore/sigstore#436? |
Description
github.com/sigstore/cosign/cmd/cosign/cli/fulcio/fulcioroots
contains methods to getx509.CertPool
s representing Fulcio's root and intermediates.To do this, it calls
initRoots
, which based on the presence of aSIGSTORE_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
andpkg/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?
The text was updated successfully, but these errors were encountered: