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

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

(My mail was rejected from the dev ml, I repost it here)

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

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

(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.

(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.

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

Created attachment 13476 [details]
fix for quictls package to avoid conflicts

Created attachment 13477 [details]
fix for quicktls patch 1/6

Created attachment 13478 [details]
fix for quictls patch 2/6

Created attachment 13479 [details]
fix for quictls patch 3/6

Created attachment 13480 [details]
fix for quictls patch 4/6

Created attachment 13481 [details]
fix for quictls patch 5/6

Created attachment 13482 [details]
fix for quictls patch 6/6

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

(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?

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.

The nvidia ones weren't in the standard lib directory, and this package simply isn't needed.

(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

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

I apply that as soon as I have a little time to do it.

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.

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

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.

(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...).

(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.

(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 ?

(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.

David, may you please confirm that it's resolved so I may close this bug report ?

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.

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.

Mark as resolved fixed, reopen if there is a problem.

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