Client: [Linux] TLSv1.3 support

[tessus]

Sorry for not filling out the template, but it's not relevent to my question.

Version 2.4.3 (build 10347)
Built from Git revision 560555 on Aug 10 2018, 21:27:04 using Qt 5.10.1, OpenSSL 1.0.2n 7 Dec 2017

When accessing my cloud site with Firefox or Chrome, TLSv1.3 is used.

However, my ownCloud client does not use TLSv1.3, but TLSv1.2. I believe this has to do with the fact that OpenSSL 1.0.2 is used. Anyway, I'm wondering if you have been looking into this.
If so, are there any plans to use OpenSSL 1.1.1 (which is the new LTS version) in the near future?

Please note that OpenSSL 1.0.2 will continue to receive full support until the end of this year. After that it will receive security fixes only. It will stop receiving all support at the end of 2019.

[michaelstingl]

@tessus Please test with the 2.5.0. What platform are you using? (I think build 10347 was built for macOS, but there we used qt5.6.2 - strange… )

All stable release builds:
https://download.owncloud.com/desktop/stable/?C=M;O=D

@jnweiger FYI ^

[dschmidt]

It depends on the platform.
2.5.0 on Windows already ships OpenSSL 1.1.
2.5.1 on macOS will also ship OpenSSL 1.1.

For Linux I suggested it yesterday to @jnweiger, but he has other priorities right now ;-)

Edit:
@jnweiger is not jw on GH...

[michaelstingl]

@tessus You could test with the latest 2.5.1 daily pre-release builds:
https://download.owncloud.com/desktop/daily/?C=M;O=D
(not for Linux yet)

[guruz]

Linux:
I'm adding this to the 2.5.1 milestone but it can also be done any time later. It implies a rebuild of our packaged Qt. We seem to be using the system OpenSSL.
https://build.opensuse.org/project/show/isv:ownCloud:desktop:client-2.5.0
libssl1.0-dev | libssl-dev

[michaelstingl]

Yeah, idea was to rely on the system SSL. If someone has ancient Linux, then only ancient SSL is available. What are the reasons to changes this? Benefits? Would would be the effort to change this?

[guruz]

CC @hefee @dragotin for input if systems ship both OpenSSL 1.0 and 1.1.

Maybe we can try to use 1.1 always and fallback to 1.0 if needed?

I don't think we should go through effort to ship ourn own OpenSSL

[tessus]

Thank you guys for all your replies. Here are my answers to your questions:

Please test with the 2.5.0. What platform are you using? (I think build 10347 was built for macOS, but there we used qt5.6.2 - strange… )

Yes, I am using macOS and yes the release on the web site points to the qt5.6.2 binary. However, in the same directory is the one with qt5.10.1 and I need that one to work with http2.
Unfortunately I am afraid to test 2.5.0. When it came out I waited for about a week and read up on the issues. There were a few that involved crashes, not syncing properly, and even data loss.
Sorry, I am not ready to replace my current version yet.

2.5.1 on macOS will also ship OpenSSL 1.1.
For Linux I suggested it yesterday to @jnweiger, but he has other priorities right now ;-)

Thank you. This is good to know and also explains why the topic changed to [Linux].... ;-)

you could test with the latest 2.5.1 daily pre-release builds:
https://download.owncloud.com/desktop/daily/?C=M;O=D
(not for Linux yet)

As mentioned before, I'm a bit reluctant to test this, unless there's a way to run them in parallel and use different accounts/settings/profiles.

Yeah, idea was to rely on the system SSL. If someone has ancient Linux, then only ancient SSL is available. What are the reasons to changes this? Benefits? Would would be the effort to change this?

The problem with this is that even on newer systems distributors often use ancient OpenSSL versions.

I don't think we should go through effort to ship ourn own OpenSSL

I don't quite follow. What do you mean by _ship your own_? All you need is to statically link openssl. That's all.

[michaelstingl]

As mentioned before, I'm a bit reluctant to test this, unless there's a way to run them in parallel and use different accounts/settings/profiles.

The testpilotcloud clients can be installed in parallel. They have own settings, own accounts etc…

[dragotin]

@guruz yes, openSUSE has both openssl 1.0 and 1.1

[dschmidt]

@guruz yes, openSUSE has both openssl 1.0 and 1.1

Yep, we probably "only" need to adjust our build specs to install 1.1 where available and Qt should pick up whichever we installed...

[guruz]

All you need is to statically link openssl. That's all.

I think this is only officially supported (by Qt) if we link Qt and the client itself statically too. (which we have considered before but decided against)
http://code.qt.io/cgit/qt/qtbase.git/tree/src/network/configure.json?h=v5.10.1#n14

[tessus]

I think this is only officially supported (by Qt) if we link Qt and the client itself statically too. (which we have considered before but decided against)

Now I'm confused. According to @dschmidt 2.5.0 on Windows already ships OpenSSL 1.1. and 2.5.1 on macOS will also ship OpenSSL 1.1.

First of all I hope @dschmidt meant OpenSSL 1.1.1, which is the LTS version, OpenSSL 1.1.0 is the same as 1.0.2 when it comes to support and EOL.

So how is this possible? macOS ships LibreSSL, thus the client cannot be dynamically linked, if it really uses OpenSSL 1.1.x. Does this mean that these clients are completely static? At least 2.4.3 has a few dylibs:

[/Applications/owncloud.app/Contents/MacOS]$ ll
total 16944
drwxr-xr-x  14 root  admin      448 17 Aug 18:23 .
drwxr-xr-x   8 root  admin      256 17 Aug 18:23 ..
-rw-r--r--   1 root  admin  2027056 10 Aug 15:29 libcrypto.1.0.0.dylib
lrwxr-xr-x   1 root  admin       21 17 Aug 18:23 libocsync.0.dylib -> libocsync.2.4.3.dylib
-rwxr-xr-x   1 root  admin  1478928 10 Aug 15:29 libocsync.2.4.3.dylib
lrwxr-xr-x   1 root  admin       17 17 Aug 18:23 libocsync.dylib -> libocsync.0.dylib
lrwxr-xr-x   1 root  admin       27 17 Aug 18:23 libowncloudsync.0.dylib -> libowncloudsync.2.4.3.dylib
-rwxr-xr-x   1 root  admin  1395104 10 Aug 15:29 libowncloudsync.2.4.3.dylib
lrwxr-xr-x   1 root  admin       23 17 Aug 18:23 libowncloudsync.dylib -> libowncloudsync.0.dylib
-rwxr-xr-x   1 root  admin   110816 10 Aug 15:29 libqt5keychain.1.dylib
-rw-r--r--   1 root  admin   383568 10 Aug 15:29 libssl.1.0.0.dylib
-rwxr-xr-x   1 root  admin  3051072 10 Aug 15:29 owncloud
-rwxr-xr-x   1 root  admin    86560 10 Aug 15:29 owncloud_crash_reporter
-rwxr-xr-x   1 root  admin   124304 10 Aug 15:29 owncloudcmd

Or are you saying that the build processes for Windows, macOS, and Linux are all different?

[dschmidt]

Yes, all are different - I'm working on streamlining them as much as possible.

Anyhow it is like this:
On Windows and macOS we ship a copy of OpenSSL in the .pkg/.msi installer which is installed alongside the client application.
On Linux we rely on the system version of openSSL which is a really good idea because then distros can take care of updates. Statically linking or shipping a shared library basically makea no difference: it moves the responsibility for updates from distros to us.
We should simply use distro OpenSSL 1.1 where available as I said.

P.S.: I only said 1.1 because that's what is needed for TLSv1.3 - we'll ship the most current one when we release

[guruz]

Now I'm confused.

We don't statically link OpenSSL into QtNetwork anywhere because we dynamically link to our shipped-with-client or to the system OpenSSL.

[ckamm]

@guruz @dschmidt What exactly needs to be done here, and should it target 2.5.4?

[jnweiger]

On all Linux platforms, we link with the system openssl library. The current state as seen with 2.5.4 dailies is:

• All Ubuntu, Debian, CentOS link with openssl 1.0.2 or 1.0.1
• openSUSE Leap 42.3 links with openssl 1.0.2j-fips
• openSUSE Leap 15.0 links with openssl 1.1.0h-fips
• Fedora 28 links with openssl 1.0.2o-fips
• Fedora 29 links with openssl 1.1.1 FIPS

[jnweiger]

When building qtbase, there is a check for the ssl version:

cd /usr/src/packages/BUILD/config.tests/openssl11 && MAKEFLAGS= /usr/bin/make
g++ -c -m64 -pipe -O2 -w -fPIC  -I. -I/usr/src/packages/BUILD/mkspecs/linux-g++-64 -o main.o main.cpp
g++ -m64 -Wl,-O1 -fuse-ld=gold -o openssl11 main.o   -L/opt/ownCloud/qt-5.12.1/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libssl.so /usr/lib/x86_64-linux-gnu/libcrypto.so
test config.qtbase_network.tests.openssl11 succeeded

It should be possible to make that succeed on Ubuntu-18.04 without breaking older distros.

[michaelstingl]

@tessus ownCloud desktop sync client 2.6.0 will come with openssl 1.1.1d for Windows and macOS. For Linux, we'll still rely on the system SSL.

[tessus]

Thanks for the info.

[TheOneRing]

Our upcoming app image is shipped with a recent openssl version.