[Webkit-unassigned] [Bug 202928] layout step not summarizes results to stdout when running with "--report"

Mon Oct 14 09:37:45 PDT 2019

https://bugs.webkit.org/show_bug.cgi?id=202928

Carlos Alberto Lopez Perez <clopez at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aperez at igalia.com

--- Comment #5 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to Jonathan Bedard from comment #3)
> (In reply to Carlos Alberto Lopez Perez from comment #1)
> > Seems the bug happens when the layout step fails to upload.
> > 
> > Our bots are giving this error:
> > 
> > 05:10:27.819 123196 Uploading to https://results.webkit.org ...
> > 05:10:27.892 123196 Starting new HTTPS connection (1): results.webkit.org:443
> > 05:10:28.207 123196     Failed to upload to https://results.webkit.org,
> > results server not online
> > 
> > (likely caused because results.webkit.org has an invalid SSL certificate,
> > signed by an unknown CA)
> > 
> > $ gnutls-cli  results.webkit.org:443
> > Processed 124 CA certificate(s).
> > Resolving 'results.webkit.org:443'...
> > Connecting to '17.32.208.166:443'...
> > - Certificate type: X.509
> > - Got a certificate list of 1 certificates.
> > - Certificate[0] info:
> >  - subject `C=US,ST=California,O=Apple
> > Inc.,OU=management:idms.group.764034,CN=results.webkit.org', issuer
> > `C=US,ST=California,O=Apple Inc.,CN=Apple Public Server RSA CA 12 - G1',
> > serial 0x4c75add9335798d877e2d8088da7118f, RSA key 2048 bits, signed using
> > RSA-SHA256, activated `2019-09-03 22:15:05 UTC', expires `2021-10-02
> > 22:15:05 UTC', pin-sha256="HWRWOw3Y56CfV1OWXgeT3mEren7q+ACX3K8c03MCTIc="
> > 	Public Key ID:
> > 		sha1:421918b7a3df5b5b160b2aa2a2ae6dbb6c97a279
> > 		sha256:1d64563b0dd8e7a09f5753965e0793de612b7a7eeaf80097dcaf1cd373024c87
> > 	Public Key PIN:
> > 		pin-sha256:HWRWOw3Y56CfV1OWXgeT3mEren7q+ACX3K8c03MCTIc=
> > 
> > - Status: The certificate is NOT trusted. The certificate issuer is unknown. 
> > *** PKI verification of server certificate failed...
> > *** Fatal error: Error in the certificate.
> 
> I temporarily turned off the verification in r250997 because our Catalina
> bots where encountering a similar problem.

Digging more into this:

 - By default Debian 10 (which our bots run) only accepts(In reply to Jonathan Bedard from comment #3)
> (In reply to Carlos Alberto Lopez Perez from comment #1)
> > Seems the bug happens when the layout step fails to upload.
> > 
> > Our bots are giving this error:
> > 
> > 05:10:27.819 123196 Uploading to https://results.webkit.org ...
> > 05:10:27.892 123196 Starting new HTTPS connection (1): results.webkit.org:443
> > 05:10:28.207 123196     Failed to upload to https://results.webkit.org,
> > results server not online
> > 
> > (likely caused because results.webkit.org has an invalid SSL certificate,
> > signed by an unknown CA)
> > 
> > $ gnutls-cli  results.webkit.org:443
> > Processed 124 CA certificate(s).
> > Resolving 'results.webkit.org:443'...
> > Connecting to '17.32.208.166:443'...
> > - Certificate type: X.509
> > - Got a certificate list of 1 certificates.
> > - Certificate[0] info:
> >  - subject `C=US,ST=California,O=Apple
> > Inc.,OU=management:idms.group.764034,CN=results.webkit.org', issuer
> > `C=US,ST=California,O=Apple Inc.,CN=Apple Public Server RSA CA 12 - G1',
> > serial 0x4c75add9335798d877e2d8088da7118f, RSA key 2048 bits, signed using
> > RSA-SHA256, activated `2019-09-03 22:15:05 UTC', expires `2021-10-02
> > 22:15:05 UTC', pin-sha256="HWRWOw3Y56CfV1OWXgeT3mEren7q+ACX3K8c03MCTIc="
> > 	Public Key ID:
> > 		sha1:421918b7a3df5b5b160b2aa2a2ae6dbb6c97a279
> > 		sha256:1d64563b0dd8e7a09f5753965e0793de612b7a7eeaf80097dcaf1cd373024c87
> > 	Public Key PIN:
> > 		pin-sha256:HWRWOw3Y56CfV1OWXgeT3mEren7q+ACX3K8c03MCTIc=
> > 
> > - Status: The certificate is NOT trusted. The certificate issuer is unknown. 
> > *** PKI verification of server certificate failed...
> > *** Fatal error: Error in the certificate.
> 
> I temporarily turned off the verification in r250997 because our Catalina
> bots where encountering a similar problem.

Digging more into this:

 - By default Debian 10 (which our bots run) only accept SSL connections
 with at least TLSv1.2

 - results.webkit.org is not able to do anything better than TLSv1.0.
 Check: https://www.ssllabs.com/ssltest/analyze.html?d=results.webkit.org

 - So even when running with Verify=false it fails because it isn't able
 to even do the handshake, check:

 $ python
Python 2.7.16 (default, Apr  6 2019, 01:42:57) 
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> p=requests.post('https://results.webkit.org/api/upload',headers={'Content-type': 'application/json'},data="",verify=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "requests/api.py", line 116, in post
    return request('post', url, data=data, json=json, **kwargs)
  File "requests/api.py", line 60, in request
    return session.request(method=method, url=url, **kwargs)
  File "requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "requests/sessions.py", line 646, in send
    r = adapter.send(request, **kwargs)
  File "requests/adapters.py", line 514, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='results.webkit.org', port=443): Max retries exceeded with url: /api/upload (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl_choose_client_version', 'unsupported protocol')],)",),))
>>> 

 - We already had a similar issue on our EWS bots, where we had to downgrade
 the security settings of Debian to accept TLSv1.0 because the server hosting
 the EWS master was also providing SSL with deprecated encryption settings.

 - We can do something similar here, I can set our buildbot bots to accept SSL with
 TLSv1.0 if upgrading that server to provide more modern SSL settings is
 difficult for you. But I guess this is only going to keep causing issues
 in the future, upgrading that server in your end to support TLSv1.2 would
 be nice.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191014/f3fa9942/attachment.html>