-
Notifications
You must be signed in to change notification settings - Fork 558
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
Switch to calling gRPC-based fulcio v2 APIs #1762
Conversation
Signed-off-by: Bob Callaway <[email protected]>
Signed-off-by: Bob Callaway <[email protected]>
Signed-off-by: Bob Callaway <[email protected]>
Hmm it looks like you might be hitting similar code-gen issues I ran into. You'll need to run Even after updating the codegen for cosigned I hit some CI issues... no sure what is up there |
If we're close to getting GRPC running in prod I'll close my PR in favour of yours as well |
Signed-off-by: Bob Callaway <[email protected]>
Signed-off-by: Bob Callaway <[email protected]>
Signed-off-by: Bob Callaway <[email protected]>
Codecov Report
@@ Coverage Diff @@
## main #1762 +/- ##
==========================================
+ Coverage 30.48% 30.63% +0.14%
==========================================
Files 136 136
Lines 8384 8442 +58
==========================================
+ Hits 2556 2586 +30
- Misses 5494 5520 +26
- Partials 334 336 +2
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Signed-off-by: Bob Callaway <[email protected]>
@bobcallaway is it worth resurrecting my other PR just to unblock bumping the Fulcio library here? Or are we pretty close to being able to switch over to GRPC with this work? |
i'm almost done with a rebase on this; where do we stand on getting the v0.4.0 fulcio code into prod? |
Should be next week. I just need to cut over the IPs in DNS. |
cc @k4leung4 |
We're discussing a rollout plan - Will ping this PR once Fulcio's been updated |
@bobcallaway .4 is out! This should be good to go |
yes, that was the intent.
…On Thu, Jun 2, 2022 at 11:51 AM Hayden B ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In cmd/cosign/cli/fulcio/fulcio.go
<#1762 (comment)>:
> fulcioServer, err := url.Parse(fulcioURL)
if err != nil {
return nil, err
}
- fClient := api.NewClient(fulcioServer, api.WithUserAgent(clioptions.UserAgent()))
- return fClient, nil
+ host := fulcioServer.Host
+ switch fulcioServer.Scheme {
+ case "https":
+ opts = append(opts, grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{MinVersion: tls.VersionTLS12})))
+ if fulcioServer.Port() == "" {
+ host = fmt.Sprintf("%s:443", host)
+ }
+ default:
Why do we have the option for an insecure mode? For local testing?
—
Reply to this email directly, view it on GitHub
<#1762 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAVWTJOCE7YSQBDBSPS7ZVDVNDJ7DANCNFSM5TO3UCEA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
cmd/cosign/cli/fulcio/fulcio.go
Outdated
return fClient, nil | ||
host := fulcioServer.Host | ||
switch fulcioServer.Scheme { | ||
case "https": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've also seen dns:///foo.example.com:443
as a supported scheme for gRPC.
I also think we should allow scheme-less and match on port.
So either:
- scheme=https
- port=443
should use a TLS connection
otherwise, an insecure connection
fs, err := fulcio.NewSigner(ctx, idToken, oidcIssuer, oidcClientID, oidcClientSecret, oidcRedirectURL, fClient) | ||
if err != nil { | ||
return nil, err | ||
} | ||
|
||
// verify the sct | ||
if err := ctl.VerifySCT(ctx, fs.Cert, fs.Chain, fs.SCT); err != nil { | ||
if err := ctl.VerifySCT(ctx, []byte(fs.Cert), []byte(strings.Join(fs.Chain, "\n")), fs.SCT); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Do you want to add a TODO here to change VerifySCT to take the list of certs rather than a single PEM-encoded chain? No need to change it now, but it would be better than converting back and forth going forward
func getFulcioCert(u *apis.URL) (*x509.CertPool, error) { | ||
fClient := api.NewClient(u.URL()) | ||
rootCertResponse, err := fClient.RootCert() | ||
func getFulcioCert(fulcioURL *apis.URL) (*x509.CertPool, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be providing this client in Fulcio to avoid duplication? I had hoped setting up a gRPC connection required very little boilerplate, but given that we need scheme/port detection, it might be good to centralize it.
fyi @wlynch, who would need the same in gitsign
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
Signed-off-by: Bob Callaway <[email protected]>
I think we should be fine here because at least our implementation here (and: Switches based off of the grpc headers. So, I'd be surprised if that would break HTTP clients, since I wouldn't be expecting them to be setting grpc headers. We can add a bunch of testing for these, but I reckon it would simplify bunch of things to be able to utilize duplex. I'll try to spin up some testing for this. |
if you're checking for We did ship Fulcio v1 with the |
Just to make sure I understand, you're saying that we should retain that flag on the server side and hence be able to serve on two ports? |
We could deprecate |
Yeah, I just wanted to make sure I understood, ack!
…On Wed, Nov 30, 2022 at 8:25 AM Bob Callaway ***@***.***> wrote:
if you're checking for Content-Type that seems reasonable - I think the
code examples I had seen in the past (not the chainguard-dev one) were only
switching on HTTP 1 v 2 which didn't seem client-safe.
We did ship Fulcio v1 with the --grpc-port cmd line arg so if we retain
that ability while also having the duplex support I think we could
accommodate both.
Just to make sure I understand, you're saying that we should retain that
flag on the server side and hence be able to serve on two ports?
We could deprecate --grpc-port as a command line arg and find another way
to express the intent when launching the server, but I dont think we should
just remove the ability to run on separate ports given that Fulcio is
v1.0.0 now.
—
Reply to this email directly, view it on GitHub
<#1762 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWB45FDZ6M4C2B54LS6KUDWK55XXANCNFSM5TO3UCEA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@bobcallaway What is the status of the PR? Looks like most tests are passing |
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR was closed because it has been stalled for 10 days with no activity. |
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR was closed because it has been stalled for 10 days with no activity. |
Waiting for fulcio gRPC to be enabled in prod
@nsmith5