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

Comments

@taralx
Copy link

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

This comment has been minimized.

Copy link
Contributor

commented Jan 4, 2017

/cc @bradfitz

@rsc rsc added this to the Soon milestone Jan 4, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

commented Jan 4, 2017

@taralx

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.