Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
crypto/x509: Update test case in verify_test #40604
What version of Go are you using (
@hyangah It will be possible to click on the "ok" text at build.golang.org to see successful build logs after #34119 and #34744 are resolved. It's already implemented in my local prototype, which I need to finish. Please subscribe to those issues for updates.
Until then, it needs to be accessed manually. See here for the build log from a recent windows-amd64-2016 builder result. It contains:
The most likely explanation is there is some difference in environment between the builder (its environment variables, Windows image, etc.) and the machine used by the original issue reporter.
Our latest Windows builder images are from 2016 (Windows Server 2016), so based on @SparrowLii's comment, it's possible this would be caught on a builder with a newer Windows image. /cc @andybons @toothrot @cagedmantis @FiloSottile
This happens on my computer too. My computer is standard Windows 10. It gets updated automatically every few month without me even noticing. So this would be the same for most Windows 10 users.
I don't run all.bat regularly. But I am making runtime change, so I run all.bat and noticed this issue.
Let me know, if you need me do bisect this issue.
Certainly possible that if the builders are using a static Windows image that they aren't pulling changes to the authroot list which may cause the root store to be in a different state than on actual machines?
It could be that
So on machines with both "AddTrust External CA Root" and "AAA Certificate Services" root certs installed, windows will currently only return the AAA Cert causing the test to fail.
The systemLax flag on the test only lets the test pass if the system fails to return any chain.
I found that you can still query the chain leading up to the other root cert by calling CertGetCertificateChain with CERT_CHAIN_RETURN_LOWER_QUALITY_CONTEXTS
I've submitted 'changes' for that here https://go-review.googlesource.com/c/go/+/257257
Eventually machines might not have the original root that the test is trying to find and it'll break again, it might just be a better idea to split out the tests that are ran against a system certificate store, because testing the entire chain against a preset is just gonna keep breaking every couple months on a couple machines