Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10

• Component: CMake
• Status: RESOLVED FIXED

[Fujii Hironori]

[CMake] Bump cmake_minimum_required version to 3.10

(In reply to Michael Catanzaro from bug #199108 comment #8)
> (In reply to Fujii Hironori from bug #199108 comment #7)
> > We can bump cmake_minimum_required version to 3.10 now.
> 
> Yeah that's true. Go for it. If any EWS complain, go for it anyway and we'll
> get them fixed.

[Fujii Hironori]

Created attachment 372815 [details]
Patch

[Adrian Perez]

For the sake of checking things a bit, today I updated one of the
EWS bots to Debian Buster (to be officially released in 2019-07-06,
in a few days), which includes CMake 3.13 and the following popped up:

  webkit-patch[599]: Received URLError: "[SSL: WRONG_SIGNATURE_TYPE] wrong signature type (_ssl.c:727)" while loading None

According to the following Debian bug report it is caused by more
strict checks by (the now updated) OpenSSL 1.1.1 and in particular
the when the server uses SHA1 for signatures in certificates:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907807

Can hold this for some days and while trying to find some solution?
We can alternatively use CMake 3.13 from the Stretch Backports repo,
but eventually we *will* need to update our bots to Buster (or any
other distro which ships a newer OpenSSL) so a solution for this
issue will be needed anyway, and I would rather start looking into
it now.

[Fujii Hironori]

Thank you for working on this, Adrian.

(In reply to Adrian Perez from comment #2)
> For the sake of checking things a bit, today I updated one of the
> EWS bots to Debian Buster (to be officially released in 2019-07-06,
> in a few days), which includes CMake 3.13 and the following popped up:
> 
>   webkit-patch[599]: Received URLError: "[SSL: WRONG_SIGNATURE_TYPE] wrong
> signature type (_ssl.c:727)" while loading None
> 
> According to the following Debian bug report it is caused by more
> strict checks by (the now updated) OpenSSL 1.1.1 and in particular
> the when the server uses SHA1 for signatures in certificates:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907807

Debian openssl package is applying this patch.
https://salsa.debian.org/ondrej/openssl/blob/553fc8e61f30cd1f7a59dd38c61e1dd4bf58437d/debian/patches/Set-systemwide-default-settings-for-libssl-users.patch

What about removing "CipherString = DEFAULT@SECLEVEL=2" line from /etc/ssl/openssl.cnf ?


> Can hold this for some days and while trying to find some solution?

Sure.

[Adrian Perez]

(In reply to Fujii Hironori from comment #3)
> Thank you for working on this, Adrian.
> 
> (In reply to Adrian Perez from comment #2)
> > For the sake of checking things a bit, today I updated one of the
> > EWS bots to Debian Buster (to be officially released in 2019-07-06,
> > in a few days), which includes CMake 3.13 and the following popped up:
> > 
> >   webkit-patch[599]: Received URLError: "[SSL: WRONG_SIGNATURE_TYPE] wrong
> > signature type (_ssl.c:727)" while loading None
> > 
> > According to the following Debian bug report it is caused by more
> > strict checks by (the now updated) OpenSSL 1.1.1 and in particular
> > the when the server uses SHA1 for signatures in certificates:
> > 
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907807
> 
> Debian openssl package is applying this patch.
> https://salsa.debian.org/ondrej/openssl/blob/
> 553fc8e61f30cd1f7a59dd38c61e1dd4bf58437d/debian/patches/Set-systemwide-
> default-settings-for-libssl-users.patch
> 
> What about removing "CipherString = DEFAULT@SECLEVEL=2" line from
> /etc/ssl/openssl.cnf ?

Good find! After commenting this line, the server can be contacted
again. I have contacted Aakash, who probably can take a look at the
server in case some fix can be deployed there as well. In the meantime,
I think it's okay to edit the openssl.cnf file in the clients.

> > Can hold this for some days and while trying to find some solution?
> 
> Sure.

I am starting today with the updates to the machines where we run
bots, and will let you know once we can land this. Thanks!

[Konstantin Tokarev]

>We can alternatively use CMake 3.13 from the Stretch Backports repo,
but eventually we *will* need to update our bots to Buster 

Note that Stretch Backports receive WebKit updates, so it may be a good idea to support this configuration

[Adrian Perez]

Now we have CMake 3.13 in all our Debian bots (one of them updated
to Buster, the rest from Stretch backports for now), and CMake
3.10 in the Ubuntu bots.

Fujii, I think we can try to land this patch now :-)

[Fujii Hironori]

Created attachment 372979 [details]
Patch

[Don Olmstead]

Comment on attachment 372979 [details]
Patch

r=me

Looks like there needs to be some more work on the bots before this lands.

[Fujii Hironori]

Comment on attachment 372979 [details]
Patch

Clearing flags on attachment: 372979

Committed r246874: <https://trac.webkit.org/changeset/246874>

[Fujii Hironori]

All reviewed patches have been landed.  Closing bug.