search

skaslev / gl3w

Simple OpenGL core profile loading
http://github.com/skaslev/gl3w
The Unlicense
705 stars 157 forks source link

[build] certificate verify failed: unable to get local issuer certificate #73

Closed JackBoosY closed 3 years ago

JackBoosY commented 3 years ago

Hi guys, Recently, we got some regression when building gl3w on vcpkg pipeline test. Here is the error log:

Traceback (most recent call last):
  File "urllib\request.py", line 1346, in do_open
  File "http\client.py", line 1253, in request
  File "http\client.py", line 1299, in _send_request
  File "http\client.py", line 1248, in endheaders
  File "http\client.py", line 1008, in _send_output
  File "http\client.py", line 948, in send
  File "http\client.py", line 1422, in connect
  File "ssl.py", line 500, in wrap_socket
  File "ssl.py", line 1040, in _create
  File "ssl.py", line 1309, in do_handshake
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\buildtrees\gl3w\src\5f10c86132-7e24c6e824.clean\gl3w_gen.py", line 115, in <module>
    web = urllib2.urlopen('https://www.khronos.org/registry/EGL/api/KHR/khrplatform.h')
  File "urllib\request.py", line 214, in urlopen
  File "urllib\request.py", line 517, in open
  File "urllib\request.py", line 534, in _open
  File "urllib\request.py", line 494, in _call_chain
  File "urllib\request.py", line 1389, in https_open
  File "urllib\request.py", line 1349, in do_open
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)>

But sadly, we couldn't reproduce this issue locally.

Maybe you should disable the certificiation check.

Related: https://github.com/microsoft/vcpkg/pull/18846 https://github.com/microsoft/vcpkg/pull/18194

skaslev commented 3 years ago

This looks like a (virtual) machine misconfiguration issue on their side and ideally should be resolved at the same level, instead of disabling certificate checking by default in gl3w.

The merged workaround microsoft/vcpkg#18858 won't work long-term since glcorearb.h and khrplatform.h will keep changing and the hashes won't match.

BillyONeal commented 3 years ago

This looks like a (virtual) machine misconfiguration issue on their side and ideally should be resolved at the same level, instead of disabling certificate checking by default in gl3w.

It isn't a virtual machine misconfiguration, it is Python not trusting Let's Encrypt's new root certificate, and Khronos using Let's Encrypt. Today it works because Let's Encrypt has a peering relationship between another CA, but that will stop working in September and it will be permanently broken (until there's an updated copy of Python or they update their certs or whatever)

See discussion I had with some browser folks about it:

The merged workaround microsoft/vcpkg#18858 won't work long-term since glcorearb.h and khrplatform.h will keep changing and the hashes won't match.

Then that was already a problem. It is a design rule that installing a port always installs the same contents (unless the version changes). Changed contents needs a changed port-version, so that 2 people who install the same port get the same behavior. We value consistency over availability.

skaslev commented 3 years ago

The merged workaround microsoft/vcpkg#18858 won't work long-term since glcorearb.h and khrplatform.h will keep changing and the hashes won't match.

Then that was already a problem. It is a design rule that installing a port always installs the same contents (unless the version changes). Changed contents needs a changed port-version, so that 2 people who install the same port get the same behavior. We value consistency over availability.

Would checking in a patch with glcorearb.h and khrplatform.h fixed to some version follow the rules? Occasionally this patch can be replaced with more recently downloaded versions of the headers. gl3w_gen.py would be perfectly happy using the headers already available on the filesystem.

BillyONeal commented 3 years ago

Would checking in a patch with glcorearb.h and khrplatform.h fixed to some version follow the rules?

That's already done for glcorearb.h. (It gets injected by another port https://github.com/microsoft/vcpkg/blob/b1b4808228377515acd849b8706ee2ad25ba455d/ports/gl3w/portfile.cmake#L19 ) It would be reasonable to do for khrplatform.h too.