-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Use upstream golang/crypto for ACME EAB + move crypto fork to cert-manager org #3877
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
Conversation
It is hardcoded to HS256 in golang.org/x/crypto Also, we now use a fork of golang.org/x/crypto in cert-manager org. Signed-off-by: irbekrm <irbekrm@gmail.com>
Signed-off-by: irbekrm <irbekrm@gmail.com>
Signed-off-by: irbekrm <irbekrm@gmail.com>
/kind cleanup |
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.
a few quite minor things which I don't feel strongly about but might be worth considering! looks good, generally 😄
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.
/lgtm
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.
A couple of comments which you can address or simply answer and /unhold
if you disagree.
/lgtm
/hold
}) | ||
Expect(err).To(HaveOccurred()) | ||
Expect(err).To(MatchError(wait.ErrWaitTimeout)) | ||
}) |
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'm not convinced that we need an E2E test for this. AFAICS it demonstrates that we can include or omit the KeyAlgorithm in our API calls and that the Issuer controller marks the Issuer Ready regardless....but it doesn't really tell us anything about whether the KeyAlgorithm is used.
I was going to suggest adding a unit-test instead, for the Setup
function (above) but I see that it's over 200 lines long and has no existing unit-tests, so that might be a big rabbit hole.
Up to you. Remove this if you agree or leave it if you think it adds value.
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.
+1 to Richard's comments - I'm not sure if the e2e test provides much value (and I think a unit test would actually provide more value) - but can appreciate this is a relatively untested area as is 😬
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 added that bit to the e2e tests because this PR changes the part that e2e-tests ACME Issuer with ExternalAccountBinding- we are now only testing with an Issuer without the keyAlgorithm field.
Because of that I thought it would be good to have a basic high level e2e test that verifies that 1) an Issuer with that field can be created (gets past webhooks, becomes Ready etc) and 2) the field can be removed- which are the two things users probably would be doing? I could remove it, if it seems like it doesn't have any value.
I could look at unit testing the Setup
function. I expect that it will need some refactoring so it might be a separate PR (that could come before this PR).
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.
Seems reasonable to keep in order to verify that it all works fine with and without! 😊
/unassign |
}) | ||
Expect(err).To(HaveOccurred()) | ||
Expect(err).To(MatchError(wait.ErrWaitTimeout)) | ||
}) |
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.
+1 to Richard's comments - I'm not sure if the e2e test provides much value (and I think a unit test would actually provide more value) - but can appreciate this is a relatively untested area as is 😬
Signed-off-by: irbekrm <irbekrm@gmail.com>
b32e59f
to
d213b4b
Compare
/test pull-cert-manager-e2e-v1-20 |
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.
@irbekrm it looks like you've answered all our comments.
/lgtm
/hold
I added a /hold
comment in case you were planning to add unit-tests in this PR.
Unhold if you prefer to get this merged now.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: irbekrm, SgtCoDFish, wallrj The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Thank you @wallrj /hold cancel |
See #3220 for full context.
Up till now we used a fork of
golang/crypto
with added support for ACME External Account Binding and fetching of ACME preferred certificate chains from @meyskens GitHub account.This PR:
golang/crypto
functionality for ACME External Account Binding instead of our owngolang/crypto
fork fromcert-manager
account instead of @meyskens accountNotes:
I have forked the latest
golang/crypto
tocert-manager
org and cherry-picked @meyskens commit that implements fetching of alternative certificate chains on top of that. We can use this fork till the same functionality gets implemented upstreamThe difference between the upstream implementation of ACME EAB and our own that we have used up till now is that in upstream the MAC algorithm value is hardcoded to
HS256
. This means that theissuer.spec.acme.externalAccountBinding.keyAlgorithm
that has been 'required' so far becomes useless. This PR makes the field optional and the validating webhook now returns a warning if it is set. It is now possible (we test for that) to 1) deploy withissuer.spec.acme.externalAccountBinding.keyAlgorithm
field set 2) deploy without the field 3) deploy with, then remove.This PR was originally part of the too large #3850 that I split into smaller PRs. Once/if this gets merged, I would like to create another PR to return a warning from the validating webhook if an issuer with
spec.acme.externalAccountBinding.keyAlgorithm
field set./kind cleanup
Closes #3822