Bug 31066 - quictls OpenSSL fork should not have been imported
Summary: quictls OpenSSL fork should not have been imported
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker critical
Target Milestone: Mageia 9
Assignee: Raphael Gertz
QA Contact: Sec team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 30163
  Show dependency treegraph
 
Reported: 2022-11-02 21:21 CET by David Walser
Modified: 2022-12-09 08:03 CET (History)
4 users (show)

See Also:
Source RPM: quictls-3.0.5-1.mga9.src.rpm
CVE:
Status comment:


Attachments
fix for quictls package to avoid conflicts (10.03 KB, text/x-rpm-spec)
2022-11-04 14:24 CET, Giuseppe Ghibò
Details
fix for quicktls patch 1/6 (655 bytes, patch)
2022-11-04 14:25 CET, Giuseppe Ghibò
Details | Diff
fix for quictls patch 2/6 (5.59 KB, patch)
2022-11-04 14:27 CET, Giuseppe Ghibò
Details | Diff
fix for quictls patch 3/6 (4.12 KB, patch)
2022-11-04 14:27 CET, Giuseppe Ghibò
Details | Diff
fix for quictls patch 4/6 (862 bytes, patch)
2022-11-04 14:28 CET, Giuseppe Ghibò
Details | Diff
fix for quictls patch 5/6 (726 bytes, patch)
2022-11-04 14:28 CET, Giuseppe Ghibò
Details | Diff
fix for quictls patch 6/6 (1.45 KB, patch)
2022-11-04 14:29 CET, Giuseppe Ghibò
Details | Diff
fix for quictls package to avoid conflicts (SPEC file) (9.95 KB, text/x-rpm-spec)
2022-11-13 20:32 CET, Giuseppe Ghibò
Details

Description David Walser 2022-11-02 21:21:42 CET
Alternate TLS implementations shouldn't just be randomly imported into Mageia, given security and maintenance implications.  As Pascal pointed out on IRC, quictls really should just be a patch set for OpenSSL that should be submitted upstream.  This should be dropped before Mageia 9.
David Walser 2022-11-02 21:22:01 CET

Priority: Normal => release_blocker
Target Milestone: --- => Mageia 9

David Walser 2022-11-02 21:22:19 CET

Blocks: (none) => 30163

Comment 1 Lewis Smith 2022-11-03 20:36:48 CET
I have added it this bug to the TRACKER, but quictls was already there:
 https://bugs.mageia.org/show_bug.cgi?id=30163#c33

Assigning to Raphael who does this.

Assignee: bugsquad => mageia

Comment 2 Raphael Gertz 2022-11-04 06:26:52 CET
Le 24 octobre 2022 17:47:53 UTC, "Jani Välimaa" <wally@mageia.org> a écrit :
>Is there some reason why we should have or need this OpenSSL fork?
>
>According to upstream:
>"This fork adds APIs that can be used by QUIC implementations for
>connection handshakes. Quoting the IETF Working group charter, QUIC is
>a "UDP-based, stream-multiplexing, encrypted transport protocol." If
>you don't need QUIC, you should use the official OpenSSL distributions."
>
>I'd say we don't need QUIC and 'another security hole' in the distro to
>be supported and patched for the security issues found in the future.
>Even if they share the code base.

I wanted to give the possibility to have quic feature in haproxy (and other packages) by just rebuilding them with an option along the way of mga9 lifetime.

In theory this package should not contaminate anything in the distribution and my idea was to keep it in sync with the openssl version.

I included version 3.0.5 and not 3.0.6 because the make test of openssl version 3.0.6 fail to build because of 4 failed test recipes.

If you place your veto on this inclusion or if it is required to add a warning about security implications I will understand, I have not your experience on this matter.

My idea was to keep quictls in sync with openssl patchset and version and add a --with quic feature to haproxy spec.

Best regards
Comment 3 Raphael Gertz 2022-11-04 06:27:21 CET
(My mail was rejected from the dev ml, I repost it here)
Comment 4 Chris Denice 2022-11-04 10:25:08 CET
This package is creating conflict.

If this is just a patch, there are other means to distribute it, most proabablu outside Mageia. But, even within Mageia, you could add that patch in the SOURCES of openssl and set a conditional to apply it, defaulting it to *false*.

Then, an educated user could flip that switch for building its local patched version of openssl. In all cases, this should be made in agreement with the maintainder of openssl due to the burden added to maintain this.

My two cents.
Cheers,
Chris.

CC: (none) => eatdirt

Comment 5 papoteur 2022-11-04 10:59:25 CET
For the moment, there is issue with conflicts between the 2 packages.
Error: Transaction test error:
  file /usr/lib64/ossl-modules/fips.so from install of lib64quictls81.3-3.0.5-1.mga9.x86_64 conflicts with file from package lib64openssl3-3.0.5-2.mga9.x86_64
  file /usr/lib64/ossl-modules/legacy.so from install of lib64quictls81.3-3.0.5-1.mga9.x86_64 conflicts with file from package lib64openssl3-3.0.5-2.mga9.x86_64 

Could be the conflict because of these lines and the Provides associated:
%define sslname       openssl
%define ssllibname    %mklibname openssl 3
%define ssldevelname  %mklibname openssl -d
%define sslstaticname %mklibname openssl -s -d
?
Are these Provides really needed?
https://svnweb.mageia.org/packages/cauldron/quictls/current/SPECS/quictls.spec?view=markup#l90

CC: (none) => yves.brungard_mageia

Comment 6 Raphael Gertz 2022-11-04 13:21:20 CET
(In reply to papoteur from comment #5)
> For the moment, there is issue with conflicts between the 2 packages.
> Error: Transaction test error:
>   file /usr/lib64/ossl-modules/fips.so from install of
> lib64quictls81.3-3.0.5-1.mga9.x86_64 conflicts with file from package
> lib64openssl3-3.0.5-2.mga9.x86_64
>   file /usr/lib64/ossl-modules/legacy.so from install of
> lib64quictls81.3-3.0.5-1.mga9.x86_64 conflicts with file from package
> lib64openssl3-3.0.5-2.mga9.x86_64 
> 
> Could be the conflict because of these lines and the Provides associated:
> %define sslname       openssl
> %define ssllibname    %mklibname openssl 3
> %define ssldevelname  %mklibname openssl -d
> %define sslstaticname %mklibname openssl -s -d
> ?
> Are these Provides really needed?
> https://svnweb.mageia.org/packages/cauldron/quictls/current/SPECS/quictls.
> spec?view=markup#l90

I just removed fips, legacy and ossl-modules from lib(64)quictls.

There should be no more conflict.

These libraries contains old or compromised algorithms unlikely used with bleeding age quic usage.
Comment 7 Raphael Gertz 2022-11-04 13:25:12 CET
(In reply to Chris Denice from comment #4)
> If this is just a patch, there are other means to distribute it, most
> proabablu outside Mageia. But, even within Mageia, you could add that patch
> in the SOURCES of openssl and set a conditional to apply it, defaulting it
> to *false*.
> 
That would be nice, but it change the library major number as well, so it's not a single patch which could be added as a togglable option.

> Then, an educated user could flip that switch for building its local patched
> version of openssl. In all cases, this should be made in agreement with the
> maintainder of openssl due to the burden added to maintain this.
> 
Yep, I have doubt he is willing to include it like that...

Openssl is critical, I suspect it's best it stay in the section of critical package less touched as possible, so easily watched, updated only for cve and version upgrade.
Comment 8 Giuseppe Ghibò 2022-11-04 14:20:43 CET
The conflicts doesn't come just from the fact that they ship overlapping files, but from the internal that they provides that confuses the building system, and especially mock (mock, copr, etc.). So it won't resolve the conflicts.

Indeed openssl developers had already foresight a mechanism to ship variant of the library, through the parameter shlib_variant.

I wrote a fix, for quictls to rename the library as the -quic variant as should have been.

Basically;

libcrypto.so -> libcrypto-quic.so
libssl.so -> libssl-quic.so
includes moved to /usr/include/openssl-quic/openssl
libcrypto.pc -> renamed to libcrypto-quic.pc
libssl.pc -> renamed to libssl-quic.pc
openssl.pc -> renamed to openssl-quic.pc

in this case the provides would change to:

pkgconfig(openssl-quic)
pkgconfig(libssl-quic)
pkgconfig(libcrypto-quic)

And one have just to use those in the BRs. Then using pkgconfig with the -quic variant in the sources, all the includes and libraries are included and linked correctly.

I'll attach here the new .spec file and patches

For the MLs, check it and eventually resubscribe.

CC: (none) => ghibomgx

Comment 9 Giuseppe Ghibò 2022-11-04 14:24:39 CET
Created attachment 13476 [details]
fix for quictls package to avoid conflicts
Comment 10 Giuseppe Ghibò 2022-11-04 14:25:46 CET
Created attachment 13477 [details]
fix for quicktls patch 1/6
Comment 11 Giuseppe Ghibò 2022-11-04 14:27:02 CET
Created attachment 13478 [details]
fix for quictls patch 2/6
Comment 12 Giuseppe Ghibò 2022-11-04 14:27:35 CET
Created attachment 13479 [details]
fix for quictls patch 3/6
Comment 13 Giuseppe Ghibò 2022-11-04 14:28:20 CET
Created attachment 13480 [details]
fix for quictls patch 4/6
Comment 14 Giuseppe Ghibò 2022-11-04 14:28:47 CET
Created attachment 13481 [details]
fix for quictls patch 5/6
Comment 15 Giuseppe Ghibò 2022-11-04 14:29:37 CET
Created attachment 13482 [details]
fix for quictls patch 6/6
Comment 16 David Walser 2022-11-04 21:11:53 CET
This is the type of package that should go in a COPR.  It should not be shipped in the Mageia 9 repositories.
Comment 17 Giuseppe Ghibò 2022-11-05 20:03:08 CET
(In reply to David Walser from comment #16)

> This is the type of package that should go in a COPR.  It should not be
> shipped in the Mageia 9 repositories.

Indeed it's actually "breaking" COPR too (as it uses mock). The release quictls-3.0.5-3.mga9, while not having overlapping libs anymore, it's actually still taking over openssl. In fact the lib64quictls-devel-3.0.5-3.mga9 provides:

pkgconfig(openssl) = 3.0.5+quic
quictls-devel = 3.0.5-3.mga9
openssl-devel = 3.0.5-3.mga9

while standard openssl-devel provides:

openssl-devel = 3.0.5-2.mga9
pkgconfig(openssl) = 3.0.5

so, when you have a package requiring just "pkgconfig(openssl)", since quictls-devel has a number "3.0.5+quic" which is bigger than "3.0.5" of standard openssl, it would be used instead of the standard one. And in the end you'll get the package linked against libssl.so.81.etc instead of libssl.so.3. Ditto if a package specifies directly "BuildRequires: openssl-devel" in a attempt to use the standard openssl. In this case quictls provides openssl-devel 3.0.5-3.mga9, which is bigger than the 3.0.5-2.mga9 provided by the standard openssl.

iurt in theory shouldn't have the problem as meta-task specifies the priority (so should mageia-repos for mock). I don't know in this case how iurt is going to select the priority. Isn't it looking at the versioning?
Comment 18 Giuseppe Ghibò 2022-11-05 20:18:18 CET
Anyway it's not the first time that we have two different libs of the same name. IIRC, with libGL provided by both mesa and nvidia.
Comment 19 David Walser 2022-11-05 20:27:17 CET
The nvidia ones weren't in the standard lib directory, and this package simply isn't needed.
Comment 20 Neal Gompa 2022-11-13 15:47:38 CET
(In reply to Giuseppe Ghibò from comment #17)
> (In reply to David Walser from comment #16)
> 
> > This is the type of package that should go in a COPR.  It should not be
> > shipped in the Mageia 9 repositories.
> 
> Indeed it's actually "breaking" COPR too (as it uses mock). The release
> quictls-3.0.5-3.mga9, while not having overlapping libs anymore, it's
> actually still taking over openssl. In fact the
> lib64quictls-devel-3.0.5-3.mga9 provides:
> 
> pkgconfig(openssl) = 3.0.5+quic
> quictls-devel = 3.0.5-3.mga9
> openssl-devel = 3.0.5-3.mga9
> 
> while standard openssl-devel provides:
> 
> openssl-devel = 3.0.5-2.mga9
> pkgconfig(openssl) = 3.0.5
> 
> so, when you have a package requiring just "pkgconfig(openssl)", since
> quictls-devel has a number "3.0.5+quic" which is bigger than "3.0.5" of
> standard openssl, it would be used instead of the standard one. And in the
> end you'll get the package linked against libssl.so.81.etc instead of
> libssl.so.3. Ditto if a package specifies directly "BuildRequires:
> openssl-devel" in a attempt to use the standard openssl. In this case
> quictls provides openssl-devel 3.0.5-3.mga9, which is bigger than the
> 3.0.5-2.mga9 provided by the standard openssl.
> 
> iurt in theory shouldn't have the problem as meta-task specifies the
> priority (so should mageia-repos for mock). I don't know in this case how
> iurt is going to select the priority. Isn't it looking at the versioning?

The problem here is that you've given it the Provides "openssl-devel". The selection is based on capabilities, and you've made it "equivalent". For the other ones we have, that's not been done, and that's why everything is getting confused.

I think if you rip out the "openssl-devel" Provides from quictls-devel, that should make things go back to being more reasonable.

I would also suggest that its pkgconfig files get changed as mentioned in comment 8. Note that you *will* need to edit the pc files too because pkgconf reads the name in the file for generating the provides too.

CC: (none) => ngompa13

Comment 21 Giuseppe Ghibò 2022-11-13 20:32:01 CET
Created attachment 13498 [details]
fix for quictls package to avoid conflicts (SPEC file)

Please Rafael, rebuild the package using this new spec file (and the included patchset). Your change in current svn has not resolved the problem in MOCK and COPR, and we get packages broken when building using them.

With this version there are no overlapping of provides and conflicts with openssl-devel, and quictls will behave like any other package; here is the new provides:

config(quictls) = 3.0.5-5.mga9
lib64openssl-quic3 = 3.0.5-5.mga9
lib64openssl-quic-devel = 3.0.5-5.mga9
lib64openssl-quic-static-devel = 3.0.5-5.mga9
lib64quictls81.3 = 3.0.5-5.mga9
lib64quictls-devel = 3.0.5-5.mga9
lib64quictls-static-devel = 3.0.5-5.mga9
openssl-quic-devel = 3.0.5-5.mga9
openssl-quic-static-devel = 3.0.5-5.mga9
pkgconfig(libcrypto-quic) = 3.0.5+quic
pkgconfig(libssl-quic) = 3.0.5+quic
pkgconfig(openssl-quic) = 3.0.5+quic
quictls = 3.0.5-5.mga9
quictls-devel = 3.0.5-5.mga9
quictls-perl = 3.0.5-5.mga9
quictls-static-devel = 3.0.5-5.mga9

Attachment 13476 is obsolete: 0 => 1

Comment 22 Raphael Gertz 2022-11-14 16:34:55 CET
I apply that as soon as I have a little time to do it.
Comment 23 Raphael Gertz 2022-12-03 04:05:14 CET
Should be resolved with lastest quictls-3.0.5-4.mga9 which include all the suggested patchset.

I reviewed the provides, plz confirm if I made a mistake.

The only drawback is that to build against quictls you need to change the includedir and libraries name.

For example in haproxy with quic enabled (not by default), I need to add -I/usr/include/openssl-quic and replace -lcrypto -lssl with -lcrypto-quic -lssl-quic using a patch on the Makefile.
Comment 24 papoteur 2022-12-03 10:37:23 CET
Hello Raphael,
I confirm that I have no more encountered installation conflicts for some weeks.
Comment 25 Giuseppe Ghibò 2022-12-03 11:10:16 CET
Ok, copr and mocks works again when there is a pkgconfig(openssl) or openssl-devel in BuildRrequires.

For the drawback, yes, but better to use pkg-config, e.g.

pkg-config --cflags libcrypto-quic libssl-quic

for the includes, and:

pkg-config --libs libcrypto-quic libssl-quic

for the libs.

BTW, the devel subpackage should also add a require:

%package -n %{develname}
...
Requires:   %{libname} = %{version}-%{release}

and the

Requires: %{develname} = %{version}-%{release}

removed.
Comment 26 Giuseppe Ghibò 2022-12-03 11:13:14 CET
(In reply to papoteur from comment #24)

> Hello Raphael,
> I confirm that I have no more encountered installation conflicts for some
> weeks.

Papoteur, there were no conflicts anymore in the past weeks, but before this latest fix quictls-devel was used instead of openssl-devel when there was a simple pkgconfig(openssl) in BR, and you saw packages linked against it (libssl.so.81...).
Comment 27 Raphael Gertz 2022-12-03 18:05:01 CET
(In reply to Giuseppe Ghibò from comment #25)
> Ok, copr and mocks works again when there is a pkgconfig(openssl) or
> openssl-devel in BuildRrequires.
> 
> For the drawback, yes, but better to use pkg-config, e.g.
> 
> pkg-config --cflags libcrypto-quic libssl-quic
> 
> for the includes, and:
> 
> pkg-config --libs libcrypto-quic libssl-quic
> 
> for the libs.
Thanks I used this configuration in haproxy patch.

> BTW, the devel subpackage should also add a require:
> 
> %package -n %{develname}
> ...
> Requires:   %{libname} = %{version}-%{release}
> 
> and the
> 
> Requires: %{develname} = %{version}-%{release}
> 
> removed.
My mistake, I confounded Requies with Provides, it should be fixed now.
Comment 28 Raphael Gertz 2022-12-03 18:05:55 CET
(In reply to Giuseppe Ghibò from comment #26)
> (In reply to papoteur from comment #24)
> 
> > Hello Raphael,
> > I confirm that I have no more encountered installation conflicts for some
> > weeks.
> 
> Papoteur, there were no conflicts anymore in the past weeks, but before this
> latest fix quictls-devel was used instead of openssl-devel when there was a
> simple pkgconfig(openssl) in BR, and you saw packages linked against it
> (libssl.so.81...).

It will be fixed with the remaining general rebuild before release, no ?
Comment 29 Giuseppe Ghibò 2022-12-03 18:19:13 CET
(In reply to Raphael Gertz from comment #28)

> (In reply to Giuseppe Ghibò from comment #26)
> > (In reply to papoteur from comment #24)
> > 
> > > Hello Raphael,
> > > I confirm that I have no more encountered installation conflicts for some
> > > weeks.
> > 
> > Papoteur, there were no conflicts anymore in the past weeks, but before this
> > latest fix quictls-devel was used instead of openssl-devel when there was a
> > simple pkgconfig(openssl) in BR, and you saw packages linked against it
> > (libssl.so.81...).
> 
> It will be fixed with the remaining general rebuild before release, no ?

yes, everything seems ok now, and starting from 3.0.5-5.mga9, we have quictls working too indipendently from openssl.
Comment 30 Raphael Gertz 2022-12-03 18:41:09 CET
David, may you please confirm that it's resolved so I may close this bug report ?
Comment 31 David Walser 2022-12-03 18:52:53 CET
The conflicts may have been solved, but the maintenance concerns are not.  I still maintain that it's not appropriate to ship this package in a stable release.  Also, the mass rebuild has long since been done, so if there were packages that were incorrectly linked linked to this, you need to rebuild them.
Comment 32 Raphael Gertz 2022-12-04 02:32:20 CET
Under cauldron:

$ urpmq --whatrequires lib64quictls81.3
lib64quictls-devel
lib64quictls-static-devel
lib64quictls81.3
quictls

$ for i in $(urpmq --whatrequires lib64openssl3); do urpmq -q --requires $i 2>/dev/null | grep -E '(crypto|ssl)' | grep 81.3; done
(empty)

So it seems no package is built against quictls lib.

Did I miss a check ?

I find it fine to have and easy-to-maintain library package and enable the quic feature by rebuilding the server or client you want to enable it for at your own risk.
You need enough knowledge to patch the configure/makefile to get it to build against the quictls alternative.

Seems it's resolved for me.
Comment 33 Raphael Gertz 2022-12-09 08:03:23 CET
Mark as resolved fixed, reopen if there is a problem.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.