36d74d6fed0f383a535f280944e1e2dc24844b67
I introduced this problem in change set 33 when I redefined RejectionReason from a uint32 to an int. I have added a test to verify the message can be marshaled correctly. This was a bit hard to track down as the recover in clientConn mainLoop would catch the panic and shutdown the connection. We probably shouldn't be using panic inside marshal/unmarshal, at least not without a way to let the user know why the recover logic tripped. R=agl, kardianos, gustav.paul CC=golang-dev https://golang.org/cl/6210063
This repository holds supplementary Go cryptography libraries. To submit changes to this repository, see http://golang.org/doc/contribute.html.
Description
Mirror of ys-ll/crypto (GitHub), kept for paraterm builds
https://golang.org/x/crypto
8.1 MiB
Languages
Go
88.6%
Assembly
11.1%
C
0.3%