-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: sometimes uses AuthzURLs slice from client.WaitOrder rather than client.AuthorizeOrder #35225
Labels
Milestone
Comments
dmitshur
added
the
NeedsFix
The path to resolution is known, but the work has not been done.
label
Oct 29, 2019
Change https://golang.org/cl/203919 mentions this issue: |
c-expert-zigbee
pushed a commit
to c-expert-zigbee/crypto_go
that referenced
this issue
Mar 28, 2022
…ePendingAuthz Previously, the o.AuthzURLs slice was sometimes used from the call to client.WaitOrder at the bottom of the for loop. By that point, o may be nil if client.WaitOrder returned an error, which would cause a nil pointer dereference panic inside the deferred function call. If client.WaitOrder did not return an error, then the call to deactivatePendingAuthz would use its AuthzURLs slice instead of the one from client.AuthorizeOrder. Fixes golang/go#35225 Updates golang/go#21081 Change-Id: I7db055ee1149871b6e5d34a8618526899c68f827 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/203919 Reviewed-by: Alex Vaghin <[email protected]>
c-expert-zigbee
pushed a commit
to c-expert-zigbee/crypto_go
that referenced
this issue
Mar 29, 2022
…ePendingAuthz Previously, the o.AuthzURLs slice was sometimes used from the call to client.WaitOrder at the bottom of the for loop. By that point, o may be nil if client.WaitOrder returned an error, which would cause a nil pointer dereference panic inside the deferred function call. If client.WaitOrder did not return an error, then the call to deactivatePendingAuthz would use its AuthzURLs slice instead of the one from client.AuthorizeOrder. Fixes golang/go#35225 Updates golang/go#21081 Change-Id: I7db055ee1149871b6e5d34a8618526899c68f827 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/203919 Reviewed-by: Alex Vaghin <[email protected]>
c-expert-zigbee
pushed a commit
to c-expert-zigbee/crypto_go
that referenced
this issue
Mar 29, 2022
…ePendingAuthz Previously, the o.AuthzURLs slice was sometimes used from the call to client.WaitOrder at the bottom of the for loop. By that point, o may be nil if client.WaitOrder returned an error, which would cause a nil pointer dereference panic inside the deferred function call. If client.WaitOrder did not return an error, then the call to deactivatePendingAuthz would use its AuthzURLs slice instead of the one from client.AuthorizeOrder. Fixes golang/go#35225 Updates golang/go#21081 Change-Id: I7db055ee1149871b6e5d34a8618526899c68f827 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/203919 Reviewed-by: Alex Vaghin <[email protected]>
LewiGoddard
pushed a commit
to LewiGoddard/crypto
that referenced
this issue
Feb 16, 2023
…ePendingAuthz Previously, the o.AuthzURLs slice was sometimes used from the call to client.WaitOrder at the bottom of the for loop. By that point, o may be nil if client.WaitOrder returned an error, which would cause a nil pointer dereference panic inside the deferred function call. If client.WaitOrder did not return an error, then the call to deactivatePendingAuthz would use its AuthzURLs slice instead of the one from client.AuthorizeOrder. Fixes golang/go#35225 Updates golang/go#21081 Change-Id: I7db055ee1149871b6e5d34a8618526899c68f827 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/203919 Reviewed-by: Alex Vaghin <[email protected]>
BiiChris
pushed a commit
to BiiChris/crypto
that referenced
this issue
Sep 15, 2023
…ePendingAuthz Previously, the o.AuthzURLs slice was sometimes used from the call to client.WaitOrder at the bottom of the for loop. By that point, o may be nil if client.WaitOrder returned an error, which would cause a nil pointer dereference panic inside the deferred function call. If client.WaitOrder did not return an error, then the call to deactivatePendingAuthz would use its AuthzURLs slice instead of the one from client.AuthorizeOrder. Fixes golang/go#35225 Updates golang/go#21081 Change-Id: I7db055ee1149871b6e5d34a8618526899c68f827 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/203919 Reviewed-by: Alex Vaghin <[email protected]>
desdeel2d0m
added a commit
to desdeel2d0m/crypto
that referenced
this issue
Jul 1, 2024
…ePendingAuthz Previously, the o.AuthzURLs slice was sometimes used from the call to client.WaitOrder at the bottom of the for loop. By that point, o may be nil if client.WaitOrder returned an error, which would cause a nil pointer dereference panic inside the deferred function call. If client.WaitOrder did not return an error, then the call to deactivatePendingAuthz would use its AuthzURLs slice instead of the one from client.AuthorizeOrder. Fixes golang/go#35225 Updates golang/go#21081 Change-Id: I7db055ee1149871b6e5d34a8618526899c68f827 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/203919 Reviewed-by: Alex Vaghin <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
In CL 199520, a new
Manager.verifyRFC
method was added. It has a deferred function call inside a for loop:The variable
o
is captured by the deferred closure. The results of callingclient.WaitOrder
are assigned too
anderr
, which changes the value ofo
that the deferred closure uses. The variableo
can becomenil
, which would cause a panic. It can be non-nil
which may change theAuthzURLs
slice in the call tom.deactivatePendingAuthz
.The text was updated successfully, but these errors were encountered: