Skip to content
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

x/crypto/acme/autocert: Persistent cache results in stuck configuration if TOS is not always accepted #18433

Open
taralx opened this issue Dec 26, 2016 · 5 comments
Milestone

Comments

@taralx
Copy link

@taralx taralx commented Dec 26, 2016

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.6

What operating system and processor architecture are you using (go env)?

amd64

What did you do?

Create a Manager that will not accept the TOS, but that does have a persistent Cache. Then re-use the cache with a Manager that does accept the TOS.

What did you expect to see?

First Manager fails to register, second Manager succeeds.

What did you see instead?

Seconds Manager also fails because acme.UpdateReg is never called.
See #18379 for the acme side of this.

@taralx taralx changed the title x/crypto/acme/autocert x/crypto/acme/autocert: Persistent cache results in stuck configuration if TOS is not always accepted Dec 26, 2016
@rsc
Copy link
Contributor

@rsc rsc commented Jan 4, 2017

/cc @bradfitz

@rsc rsc added this to the Soon milestone Jan 4, 2017
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jan 4, 2017

I have the same comment here as #18379 --- don't disagree with the TOS sometimes and expect things to work.

That said, @x1ddos can prioritize a fix as his schedule allows.

Alternatively, feel free to send a fix yourself if it has tests.

@x1ddos
Copy link

@x1ddos x1ddos commented Jan 4, 2017

@taralx
Copy link
Author

@taralx taralx commented Jan 4, 2017

If the only supported configuration is "accept the TOS", then perhaps the function should be replaced with a boolean, and passing "false" should cause an error without attempting registration at all.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jan 4, 2017

No, you're right... if it's there it should work. But it's only there as a formality, not because we expected anybody to use it.

@titanous titanous modified the milestones: Unreleased, Soon Jan 7, 2017
@x1ddos x1ddos removed their assignment Mar 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants