7:49 a.m.
Hi all,
the openssl will be rebased in Rawhide to 1.1.0 on Monday. There will
be also 1.0.2 compat package (compat-openssl10) so the dependencies are
not broken and Rawhide should be installable. Also things that do not
depend on openssl should be rebuildable without changes.
On the other hand due to the major API changes in 1.1.0 if your package
uses OpenSSL it will not be possible to rebuild it without patching.
Some upstreams already updated their code to work with 1.1.0 so if it
is your case again there might not be any problems rebuilding it.
I will be also working on patching and rebuilding the dependencies
starting with minimal install and expanding to broader installs of
Fedora. However there might be cases where the package is using some
obscure features of the old 1.0.x API and the port might be non-trivial
- I do not expect such packages to be common however cooperation with
the respective package upstream might be needed in such cases.
At worst if the patching of a package is highly non-trivial and the
upstream is not responsive we might have to drop the package from
Fedora.
We do not want to keep 1.0.2 devel around as that could make it to look
like the 1.0.2 is still fully "supported" in Fedora and there would be
no incentive to switch to 1.1.0. Also to get any new features from
upstream OpenSSL we have to move to newer versions as they are released
as the old versions get only bug fixes.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
6:37 a.m.
Tomas Mraz wrote:
At worst if the patching of a package is highly non-trivial and the
upstream is not responsive we might have to drop the package from
Fedora.
We do not want to keep 1.0.2 devel around as that could make it to look
like the 1.0.2 is still fully "supported" in Fedora and there would be
no incentive to switch to 1.1.0. Also to get any new features from
upstream OpenSSL we have to move to newer versions as they are released
as the old versions get only bug fixes.
IMHO, this is not acceptable. If the API of a library changes enough to
warrant a compat package, you have to provide the -devel for the compat
package as well. Dropping all the packages that don't build against the new
incompatible version from Fedora is not a reasonable plan.
Kevin Kofler
9:24 a.m.
On Sat, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
Tomas Mraz wrote:
> At worst if the patching of a package is highly non-trivial and the
> upstream is not responsive we might have to drop the package from
> Fedora.
>
> We do not want to keep 1.0.2 devel around as that could make it to look
> like the 1.0.2 is still fully "supported" in Fedora and there would be
> no incentive to switch to 1.1.0. Also to get any new features from
> upstream OpenSSL we have to move to newer versions as they are released
> as the old versions get only bug fixes.
IMHO, this is not acceptable. If the API of a library changes enough to
warrant a compat package, you have to provide the -devel for the compat
package as well. Dropping all the packages that don't build against the new
incompatible version from Fedora is not a reasonable plan.
I think the idea is that we fix them, not drop them.
--
dwmw2
9:29 a.m.
On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
Tomas Mraz wrote:
>
> At worst if the patching of a package is highly non-trivial and the
> upstream is not responsive we might have to drop the package from
> Fedora.
>
> We do not want to keep 1.0.2 devel around as that could make it to
> look
> like the 1.0.2 is still fully "supported" in Fedora and there would
> be
> no incentive to switch to 1.1.0. Also to get any new features from
> upstream OpenSSL we have to move to newer versions as they are
> released
> as the old versions get only bug fixes.
IMHO, this is not acceptable. If the API of a library changes enough
to
warrant a compat package, you have to provide the -devel for the
compat
package as well. Dropping all the packages that don't build against
the new
incompatible version from Fedora is not a reasonable plan.
We will work on porting the dependent packages to the new API. If by
some reasonable deadline there are still some packages that are not
dead by other reasons and we are unable to port them we can add -devel
to the compat package. Note though that small changes in such packages
will be needed anyway as the include files of the compat package will
have to be in non-default include directory. (If the package doesn't
use pkgconfig to find the needed CFLAGS automatically.)
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
6:09 a.m.
Le 10/10/2016 à 16:29, Tomas Mraz a écrit :
On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
> Tomas Mraz wrote:
>>
>> At worst if the patching of a package is highly non-trivial and the
>> upstream is not responsive we might have to drop the package from
>> Fedora.
>>
>> We do not want to keep 1.0.2 devel around as that could make it to
>> look
>> like the 1.0.2 is still fully "supported" in Fedora and there would
>> be
>> no incentive to switch to 1.1.0. Also to get any new features from
>> upstream OpenSSL we have to move to newer versions as they are
>> released
>> as the old versions get only bug fixes.
> IMHO, this is not acceptable. If the API of a library changes enough
> to
> warrant a compat package, you have to provide the -devel for the
> compat
> package as well. Dropping all the packages that don't build against
> the new
> incompatible version from Fedora is not a reasonable plan.
We will work on porting the dependent packages to the new API. If by
some reasonable deadline there are still some packages that are not
dead by other reasons and we are unable to port them we can add -devel
to the compat package. Note though that small changes in such packages
will be needed anyway as the include files of the compat package will
have to be in non-default include directory. (If the package doesn't
use pkgconfig to find the needed CFLAGS automatically.)
PHP version 7.0.x is not compatible with OpenSSL 1.1
The work is 'in progress' in PHP master (which will be 7.2)
I will start to work on backporting the various upstream patches, but
perhaps will be simple to first update to 7.1.x (current version is RC3)
It doesn't seem possible to use a compat library (else we will very
probably going to encounter issues is both library versions are used in
the same process, because of the numerous libraries linked to PHP or its
extensions)
Remi.
6:54 a.m.
Le 11/10/2016 à 13:09, Remi Collet a écrit :
PHP version 7.0.x is not compatible with OpenSSL 1.1
But PHP 7.1 is
http://koji.fedoraproject.org/koji/taskinfo?taskID=16046780
So: https://fedoraproject.org/wiki/Changes/php71
Remi.
11:46 a.m.
On 2016-10-11, Remi Collet <Fedora(a)FamilleCollet.com> wrote:
It doesn't seem possible to use a compat library (else we will
very
probably going to encounter issues is both library versions are used in
the same process, because of the numerous libraries linked to PHP or its
extensions)
That's true. I was just porting a Perl package to OpenSSL 1.1.0 and
while the ported code build and passed all tests when built against old
OpenSSL, it crashed when linked to the new OpenSSL. The reason there was
another Perl package loaded into the process that was linked to the old
OpenSSL.
Therefore I conclude it will be necessary to rebuild all packages
requiring the old soname against new OpenSSL in the order of
dependencies.
-- Petr
12:07 p.m.
On Út, 2016-10-11 at 16:46 +0000, Petr Pisar wrote:
On 2016-10-11, Remi Collet <Fedora(a)FamilleCollet.com> wrote:
>
> It doesn't seem possible to use a compat library (else we will very
> probably going to encounter issues is both library versions are
> used in
> the same process, because of the numerous libraries linked to PHP
> or its
> extensions)
>
That's true. I was just porting a Perl package to OpenSSL 1.1.0 and
while the ported code build and passed all tests when built against
old
OpenSSL, it crashed when linked to the new OpenSSL. The reason there
was
another Perl package loaded into the process that was linked to the
old
OpenSSL.
Therefore I conclude it will be necessary to rebuild all packages
requiring the old soname against new OpenSSL in the order of
dependencies.
In my testing of application that pulled both old (indirectly) and new
OpenSSL (directly), it did not crash and I did not see anything wrong
with it. So it seems not all cases are broken however apparently the
above is reason for moving dependencies to 1.1.0 as quickly as
possible.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
1:22 a.m.
On Tue, 2016-10-11 at 16:46 +0000, Petr Pisar wrote:
On 2016-10-11, Remi Collet <Fedora(a)FamilleCollet.com> wrote:
>
> It doesn't seem possible to use a compat library (else we will very
> probably going to encounter issues is both library versions are
> used in
> the same process, because of the numerous libraries linked to PHP
> or its
> extensions)
>
That's true. I was just porting a Perl package to OpenSSL 1.1.0 and
while the ported code build and passed all tests when built against
old
OpenSSL, it crashed when linked to the new OpenSSL. The reason there
was another Perl package loaded into the process that was linked to
the old OpenSSL.
Was the load using dlopen() or simply an indirect link?
3:01 a.m.
On St, 2016-10-12 at 08:22 +0200, Nikos Mavrogiannopoulos wrote:
On Tue, 2016-10-11 at 16:46 +0000, Petr Pisar wrote:
>
> On 2016-10-11, Remi Collet <Fedora(a)FamilleCollet.com> wrote:
> >
> >
> > It doesn't seem possible to use a compat library (else we will
> > very
> > probably going to encounter issues is both library versions are
> > used in
> > the same process, because of the numerous libraries linked to PHP
> > or its
> > extensions)
> >
> That's true. I was just porting a Perl package to OpenSSL 1.1.0 and
> while the ported code build and passed all tests when built against
> old
> OpenSSL, it crashed when linked to the new OpenSSL. The reason
> there
> was another Perl package loaded into the process that was linked to
> the old OpenSSL.
Was the load using dlopen() or simply an indirect link?
Also what I would expect to crash is situation where the perl modules
linked to different OpenSSL versions try to pass the references to
OpenSSL data structures across the versions. That certainly won't work.
On the other hand the scenario where one library linked by an
application uses OpenSSL 1.1 for TLS and another library uses OpenSSL
1.0 for SHA256 hashing, should work - at least it worked for me when I
tested it.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
3:21 a.m.
On 2016-10-12, Tomas Mraz <tmraz(a)redhat.com> wrote:
On St, 2016-10-12 at 08:22 +0200, Nikos Mavrogiannopoulos wrote:
> Was the load using dlopen() or simply an indirect link?
Both Perl modules were dlopened. Each of the module linked to
different OpenSSL directly (DT_NEEDED).
Also what I would expect to crash is situation where the perl
modules
linked to different OpenSSL versions try to pass the references to
OpenSSL data structures across the versions. That certainly won't work.
Yes. It passed pointers to BIGNUM and EC_KEY between them.
-- Petr
5:39 a.m.
On St, 2016-10-12 at 08:21 +0000, Petr Pisar wrote:
On 2016-10-12, Tomas Mraz <tmraz(a)redhat.com> wrote:
>
> On St, 2016-10-12 at 08:22 +0200, Nikos Mavrogiannopoulos wrote:
> >
> > Was the load using dlopen() or simply an indirect link?
Both Perl modules were dlopened. Each of the module linked to
different OpenSSL directly (DT_NEEDED).
>
> Also what I would expect to crash is situation where the perl
> modules
> linked to different OpenSSL versions try to pass the references to
> OpenSSL data structures across the versions. That certainly won't
> work.
>
Yes. It passed pointers to BIGNUM and EC_KEY between them.
Now that surely won't work. But it should not be common scenario except
for language bindings where various modules using openssl are in
separate packages. I do not know if there are any other such languages
than perl. Usually all the bindings are in a single package or at worst
there are two packages - one for libcrypto bindings and one for libssl.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
8:21 a.m.
Just FTR, I opened Ruby upstream ticket asking about the OpenSSL 1.1.0
support:
https://bugs.ruby-lang.org/issues/12830
Not sure if you'll have also some Fedora specific tracker ....
Vít
Dne 10.10.2016 v 16:29 Tomas Mraz napsal(a):
On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
> Tomas Mraz wrote:
>> At worst if the patching of a package is highly non-trivial and the
>> upstream is not responsive we might have to drop the package from
>> Fedora.
>>
>> We do not want to keep 1.0.2 devel around as that could make it to
>> look
>> like the 1.0.2 is still fully "supported" in Fedora and there would
>> be
>> no incentive to switch to 1.1.0. Also to get any new features from
>> upstream OpenSSL we have to move to newer versions as they are
>> released
>> as the old versions get only bug fixes.
> IMHO, this is not acceptable. If the API of a library changes enough
> to
> warrant a compat package, you have to provide the -devel for the
> compat
> package as well. Dropping all the packages that don't build against
> the new
> incompatible version from Fedora is not a reasonable plan.
We will work on porting the dependent packages to the new API. If by
some reasonable deadline there are still some packages that are not
dead by other reasons and we are unable to port them we can add -devel
to the compat package. Note though that small changes in such packages
will be needed anyway as the include files of the compat package will
have to be in non-default include directory. (If the package doesn't
use pkgconfig to find the needed CFLAGS automatically.)
8:27 a.m.
On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch <vondruch(a)redhat.com> wrote:
Just FTR, I opened Ruby upstream ticket asking about the OpenSSL
1.1.0
support:
https://bugs.ruby-lang.org/issues/12830
Not sure if you'll have also some Fedora specific tracker ....
Would be nice to
get tracking bug created on RHBZ, so we can track all
the packages.
Vít
Dne 10.10.2016 v 16:29 Tomas Mraz napsal(a):
> On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
>> Tomas Mraz wrote:
>>> At worst if the patching of a package is highly non-trivial and the
>>> upstream is not responsive we might have to drop the package from
>>> Fedora.
>>>
>>> We do not want to keep 1.0.2 devel around as that could make it to
>>> look
>>> like the 1.0.2 is still fully "supported" in Fedora and there
would
>>> be
>>> no incentive to switch to 1.1.0. Also to get any new features from
>>> upstream OpenSSL we have to move to newer versions as they are
>>> released
>>> as the old versions get only bug fixes.
>> IMHO, this is not acceptable. If the API of a library changes enough
>> to
>> warrant a compat package, you have to provide the -devel for the
>> compat
>> package as well. Dropping all the packages that don't build against
>> the new
>> incompatible version from Fedora is not a reasonable plan.
> We will work on porting the dependent packages to the new API. If by
> some reasonable deadline there are still some packages that are not
> dead by other reasons and we are unable to port them we can add -devel
> to the compat package. Note though that small changes in such packages
> will be needed anyway as the include files of the compat package will
> have to be in non-default include directory. (If the package doesn't
> use pkgconfig to find the needed CFLAGS automatically.)
>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
-Igor Gnatenko
11:08 a.m.
On Út, 2016-10-11 at 15:27 +0200, Igor Gnatenko wrote:
On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch
<vondruch(a)redhat.com>
wrote:
>
> Just FTR, I opened Ruby upstream ticket asking about the OpenSSL
> 1.1.0
> support:
>
> https://bugs.ruby-lang.org/issues/12830
>
> Not sure if you'll have also some Fedora specific tracker ....
Would be nice to get tracking bug created on RHBZ, so we can track
all
the packages.
Created:
https://bugzilla.redhat.com/show_bug.cgi?id=1383740
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
11:59 a.m.
On Tue, Oct 11, 2016 at 6:08 PM, Tomas Mraz <tmraz(a)redhat.com> wrote:
On Út, 2016-10-11 at 15:27 +0200, Igor Gnatenko wrote:
> On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch <vondruch(a)redhat.com>
> wrote:
> >
> > Just FTR, I opened Ruby upstream ticket asking about the OpenSSL
> > 1.1.0
> > support:
> >
> > https://bugs.ruby-lang.org/issues/12830
> >
> > Not sure if you'll have also some Fedora specific tracker ....
> Would be nice to get tracking bug created on RHBZ, so we can track
> all
> the packages.
Created:
https://bugzilla.redhat.com/show_bug.cgi?id=1383740
Thanks!
I opened couple of bugreports against my packages so I will try to fix
myself and notify upstream. Just wanted bug to track things to do.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
-Igor Gnatenko
8:39 a.m.
mongo-c-driver 1.3.5 (current version in rawhide) is not compatible.
mongo-c-driver 1.4+ is
But pecl/mongodb 1.2.0 is not yet released (alpha3) and will require
both libbson 1.5.0 and mongo-c-driver 1.5.0 (only RC for now)
So, stalled for now.
Remi.
P.S.1: v1.4 drop a private lib, only used by the PHP ext.,
so is really something I'm waiting for.
P.S.2: https://jira.mongodb.org/browse/CDRIVER-1066
7:23 p.m.
On Mon, 2016-10-10 at 16:29 +0200, Tomas Mraz wrote:
We will work on porting the dependent packages to the new API. If by
some reasonable deadline there are still some packages that are not
dead by other reasons and we are unable to port them we can add -devel
to the compat package. Note though that small changes in such packages
will be needed anyway as the include files of the compat package will
have to be in non-default include directory. (If the package doesn't
use pkgconfig to find the needed CFLAGS automatically.)
Even if it uses pkgconfig, it's still going to need to look for
openssl102.pc or whatever we call it, because just 'openssl' is going
to get it OpenSSL 1.1.
And if we *are* going to ship a separate -devel package for 1.0.2 and
1.1 in parallel we are *really* going to need to make sure that
*neither* of them live in /usr/include/openssl/ where they can be
picked up by default.
--
dwmw2
2:55 a.m.
On St, 2016-10-12 at 01:23 +0100, David Woodhouse wrote:
On Mon, 2016-10-10 at 16:29 +0200, Tomas Mraz wrote:
>
>
> We will work on porting the dependent packages to the new API. If
> by
> some reasonable deadline there are still some packages that are not
> dead by other reasons and we are unable to port them we can add
> -devel
> to the compat package. Note though that small changes in such
> packages
> will be needed anyway as the include files of the compat package
> will
> have to be in non-default include directory. (If the package
> doesn't
> use pkgconfig to find the needed CFLAGS automatically.)
Even if it uses pkgconfig, it's still going to need to look for
openssl102.pc or whatever we call it, because just 'openssl' is going
to get it OpenSSL 1.1.
And if we *are* going to ship a separate -devel package for 1.0.2 and
1.1 in parallel we are *really* going to need to make sure that
*neither* of them live in /usr/include/openssl/ where they can be
picked up by default.
I am against moving 1.1 into separate /usr/include. If we ship the
compat-openssl10-devel I will make it conflict with 1.1.0 openssl-
devel. Of course that won't allow compiling things against both
versions but that is something we do not want to allow anyway.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
3:28 a.m.
Dne 10.10.2016 v 16:29 Tomas Mraz napsal(a):
On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
> Tomas Mraz wrote:
>> At worst if the patching of a package is highly non-trivial and the
>> upstream is not responsive we might have to drop the package from
>> Fedora.
>>
>> We do not want to keep 1.0.2 devel around as that could make it to
>> look
>> like the 1.0.2 is still fully "supported" in Fedora and there would
>> be
>> no incentive to switch to 1.1.0. Also to get any new features from
>> upstream OpenSSL we have to move to newer versions as they are
>> released
>> as the old versions get only bug fixes.
> IMHO, this is not acceptable. If the API of a library changes enough
> to
> warrant a compat package, you have to provide the -devel for the
> compat
> package as well. Dropping all the packages that don't build against
> the new
> incompatible version from Fedora is not a reasonable plan.
We will work on porting the dependent packages to the new API. If by
some reasonable deadline there are still some packages that are not
dead by other reasons and we are unable to port them we can add -devel
to the compat package. Note though that small changes in such packages
will be needed anyway as the include files of the compat package will
have to be in non-default include directory. (If the package doesn't
use pkgconfig to find the needed CFLAGS automatically.)
But what about stable versions of libraries applications? For example,
in current Rawhide, you won't be able to build any stable Ruby version
downloaded as tarball without the compat-openssl-devel. And it is
question, if upstream will be able to backport the OpenSSL 1.1.0 support
into stable Ruby versions [1]. Not mentioning all the older Ruby
versions which are unsupported, but up until now, you could build them
on your own (actually it should be possible to disable the OpenSSL
support, but that is not common scenario).
I personally don't care much about this scenario, but I am pretty sure
that others might care more ....
Vít
[1] https://bugs.ruby-lang.org/issues/12830#note-2
5:40 a.m.
On St, 2016-10-12 at 10:28 +0200, Vít Ondruch wrote:
Dne 10.10.2016 v 16:29 Tomas Mraz napsal(a):
>
> On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
> >
> > Tomas Mraz wrote:
> > >
> > > At worst if the patching of a package is highly non-trivial and
> > > the
> > > upstream is not responsive we might have to drop the package
> > > from
> > > Fedora.
> > >
> > > We do not want to keep 1.0.2 devel around as that could make it
> > > to
> > > look
> > > like the 1.0.2 is still fully "supported" in Fedora and there
> > > would
> > > be
> > > no incentive to switch to 1.1.0. Also to get any new features
> > > from
> > > upstream OpenSSL we have to move to newer versions as they are
> > > released
> > > as the old versions get only bug fixes.
> > IMHO, this is not acceptable. If the API of a library changes
> > enough
> > to
> > warrant a compat package, you have to provide the -devel for the
> > compat
> > package as well. Dropping all the packages that don't build
> > against
> > the new
> > incompatible version from Fedora is not a reasonable plan.
> We will work on porting the dependent packages to the new API. If
> by
> some reasonable deadline there are still some packages that are not
> dead by other reasons and we are unable to port them we can add
> -devel
> to the compat package. Note though that small changes in such
> packages
> will be needed anyway as the include files of the compat package
> will
> have to be in non-default include directory. (If the package
> doesn't
> use pkgconfig to find the needed CFLAGS automatically.)
>
But what about stable versions of libraries applications? For
example,
in current Rawhide, you won't be able to build any stable Ruby
version
downloaded as tarball without the compat-openssl-devel. And it is
question, if upstream will be able to backport the OpenSSL 1.1.0
support
into stable Ruby versions [1]. Not mentioning all the older Ruby
versions which are unsupported, but up until now, you could build
them
on your own (actually it should be possible to disable the OpenSSL
support, but that is not common scenario).
I personally don't care much about this scenario, but I am pretty
sure
that others might care more ....
Yes, I am getting more and more inclined to ship compat-openssl10-
devel. However I will make it conflicting with openssl-devel and its
use for Fedora packages should be strongly discouraged.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
8:44 a.m.
On St, 2016-10-12 at 12:40 +0200, Tomas Mraz wrote:
On St, 2016-10-12 at 10:28 +0200, Vít Ondruch wrote:
>
> But what about stable versions of libraries applications? For
> example,
> in current Rawhide, you won't be able to build any stable Ruby
> version
> downloaded as tarball without the compat-openssl-devel. And it is
> question, if upstream will be able to backport the OpenSSL 1.1.0
> support
> into stable Ruby versions [1]. Not mentioning all the older Ruby
> versions which are unsupported, but up until now, you could build
> them
> on your own (actually it should be possible to disable the OpenSSL
> support, but that is not common scenario).
>
> I personally don't care much about this scenario, but I am pretty
> sure
> that others might care more ....
Yes, I am getting more and more inclined to ship compat-openssl10-
devel. However I will make it conflicting with openssl-devel and its
use for Fedora packages should be strongly discouraged.
So I've added compat-openssl10-devel subpackage to the compat-openssl10
package. Please use it only in case all of these three conditions are
true:
1. port of your dependent package is not straightforward
2. upstream does not work on the port
3. you are not able to port it yourself
Please also in that case fill a bug against your package and make it
block the FTBFS with OpenSSL1.1.0 tracker bug: https://bugzilla.redhat.
com/show_bug.cgi?id=1383740
If the port should be straightforward (i.e. the package does not
contain language bindings for OpenSSL, it is not an OpenSSL engine, and
it is not using OpenSSL internals deeply) but you do not have time to
work on it, please also fill the FTBFS bug and add me to CC so I can
work on the patch.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
10:25 a.m.
On 10/07/2016 06:49 AM, Tomas Mraz wrote:
Hi all,
the openssl will be rebased in Rawhide to 1.1.0 on Monday. There will
be also 1.0.2 compat package (compat-openssl10) so the dependencies are
not broken and Rawhide should be installable. Also things that do not
depend on openssl should be rebuildable without changes.
On the other hand due to the major API changes in 1.1.0 if your package
uses OpenSSL it will not be possible to rebuild it without patching.
Some upstreams already updated their code to work with 1.1.0 so if it
is your case again there might not be any problems rebuilding it.
I will be also working on patching and rebuilding the dependencies
starting with minimal install and expanding to broader installs of
Fedora. However there might be cases where the package is using some
obscure features of the old 1.0.x API and the port might be non-trivial
- I do not expect such packages to be common however cooperation with
the respective package upstream might be needed in such cases.
At worst if the patching of a package is highly non-trivial and the
upstream is not responsive we might have to drop the package from
Fedora.
We do not want to keep 1.0.2 devel around as that could make it to look
like the 1.0.2 is still fully "supported" in Fedora and there would be
no incentive to switch to 1.1.0. Also to get any new features from
upstream OpenSSL we have to move to newer versions as they are released
as the old versions get only bug fixes.
It appears that setting:
-DOPENSSL_API_COMPAT=0x10020000L
Should at least partially get you the 1.0.2 API. Although clamav's configure
test for SSL_library_init() doesn't #include <ssl.h> so that doesn't work
for
it out of the box.
Also, getting:
crypto.c: In function 'cl_load_crl':
crypto.c:1113:32: error: dereferencing pointer to incomplete type 'X509_CRL
{aka struct X509_crl_st}'
tm = cl_ASN1_GetTimeT(x->crl->nextUpdate);
^~
So looks like it doesn't work for all cases.
ClamAV upstream request: https://bugzilla.clamav.net/show_bug.cgi?id=11646
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
11:04 a.m.
On Út, 2016-10-11 at 09:25 -0600, Orion Poplawski wrote:
On 10/07/2016 06:49 AM, Tomas Mraz wrote:
>
> Hi all,
>
> the openssl will be rebased in Rawhide to 1.1.0 on Monday. There
> will
> be also 1.0.2 compat package (compat-openssl10) so the dependencies
> are
> not broken and Rawhide should be installable. Also things that do
> not
> depend on openssl should be rebuildable without changes.
>
> On the other hand due to the major API changes in 1.1.0 if your
> package
> uses OpenSSL it will not be possible to rebuild it without
> patching.
> Some upstreams already updated their code to work with 1.1.0 so if
> it
> is your case again there might not be any problems rebuilding it.
>
> I will be also working on patching and rebuilding the dependencies
> starting with minimal install and expanding to broader installs of
> Fedora. However there might be cases where the package is using
> some
> obscure features of the old 1.0.x API and the port might be non-
> trivial
> - I do not expect such packages to be common however cooperation
> with
> the respective package upstream might be needed in such cases.
>
> At worst if the patching of a package is highly non-trivial and the
> upstream is not responsive we might have to drop the package from
> Fedora.
>
> We do not want to keep 1.0.2 devel around as that could make it to
> look
> like the 1.0.2 is still fully "supported" in Fedora and there would
> be
> no incentive to switch to 1.1.0. Also to get any new features from
> upstream OpenSSL we have to move to newer versions as they are
> released
> as the old versions get only bug fixes.
>
It appears that setting:
-DOPENSSL_API_COMPAT=0x10020000L
Should at least partially get you the 1.0.2 API. Although clamav's
configure
test for SSL_library_init() doesn't #include <ssl.h> so that doesn't
work for
it out of the box.
Yes, it basically works for deprecated functions. However it does not
work for things that access structure members in the 1.0 API.
Also, getting:
crypto.c: In function 'cl_load_crl':
crypto.c:1113:32: error: dereferencing pointer to incomplete type
'X509_CRL
{aka struct X509_crl_st}'
tm = cl_ASN1_GetTimeT(x->crl->nextUpdate);
^~
So looks like it doesn't work for all cases.
Yes, all the structures are opaque regardless of OPENSSL_API_COMPAT.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
7:39 a.m.
On Friday, October 07, 2016 14:49:49 Tomas Mraz wrote:
Hi all,
the openssl will be rebased in Rawhide to 1.1.0 on Monday. There will
be also 1.0.2 compat package (compat-openssl10) so the dependencies are
not broken and Rawhide should be installable. Also things that do not
depend on openssl should be rebuildable without changes.
On the other hand due to the major API changes in 1.1.0 if your package
uses OpenSSL it will not be possible to rebuild it without patching.
Some upstreams already updated their code to work with 1.1.0 so if it
is your case again there might not be any problems rebuilding it.
Is there any migration guide regarding the API changes introduced in 1.1.0?
Kamil
> I will be also working on patching and rebuilding the dependencies
> starting with minimal install and expanding to broader installs of
> Fedora. However there might be cases where the package is using some
> obscure features of the old 1.0.x API and the port might be non-trivial
> - I do not expect such packages to be common however cooperation with
> the respective package upstream might be needed in such cases.
>
> At worst if the patching of a package is highly non-trivial and the
> upstream is not responsive we might have to drop the package from
> Fedora.
>
> We do not want to keep 1.0.2 devel around as that could make it to look
> like the 1.0.2 is still fully "supported" in Fedora and there would be
> no incentive to switch to 1.1.0. Also to get any new features from
> upstream OpenSSL we have to move to newer versions as they are released
> as the old versions get only bug fixes.
8:33 a.m.
On St, 2016-10-12 at 14:39 +0200, Kamil Dudka wrote:
On Friday, October 07, 2016 14:49:49 Tomas Mraz wrote:
>
> Hi all,
>
> the openssl will be rebased in Rawhide to 1.1.0 on Monday. There
> will
> be also 1.0.2 compat package (compat-openssl10) so the dependencies
> are
> not broken and Rawhide should be installable. Also things that do
> not
> depend on openssl should be rebuildable without changes.
>
> On the other hand due to the major API changes in 1.1.0 if your
> package
> uses OpenSSL it will not be possible to rebuild it without
> patching.
> Some upstreams already updated their code to work with 1.1.0 so if
> it
> is your case again there might not be any problems rebuilding it.
Is there any migration guide regarding the API changes introduced in
1.1.0?
Unfortunately not except for what's written here: https://wiki.openssl.
org/index.php/1.1_API_Changes#Major_Changes_so_far
Basically replacing direct access to structure members with use of
getters and setters should work. Also of course the structures cannot
be directly put into variables but allocated/destroyed via *_new *_free
functions.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
9:06 a.m.
On St, 2016-10-12 at 15:33 +0200, Tomas Mraz wrote:
On St, 2016-10-12 at 14:39 +0200, Kamil Dudka wrote:
>
> On Friday, October 07, 2016 14:49:49 Tomas Mraz wrote:
> >
> >
> > Hi all,
> >
> > the openssl will be rebased in Rawhide to 1.1.0 on Monday. There
> > will
> > be also 1.0.2 compat package (compat-openssl10) so the
> > dependencies
> > are
> > not broken and Rawhide should be installable. Also things that do
> > not
> > depend on openssl should be rebuildable without changes.
> >
> > On the other hand due to the major API changes in 1.1.0 if your
> > package
> > uses OpenSSL it will not be possible to rebuild it without
> > patching.
> > Some upstreams already updated their code to work with 1.1.0 so
> > if
> > it
> > is your case again there might not be any problems rebuilding it.
> Is there any migration guide regarding the API changes introduced
> in
> 1.1.0?
Unfortunately not except for what's written here: https://wiki.openss
l.
org/index.php/1.1_API_Changes#Major_Changes_so_far
Basically replacing direct access to structure members with use of
getters and setters should work. Also of course the structures cannot
be directly put into variables but allocated/destroyed via *_new
*_free
functions.
Also there is https://github.com/patch-exchange/openssl-1.1-transition
where you can take some inspiration.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
2744
days inactive
2751
days old
26 comments
10 participants
participants (10)
-
David Woodhouse -
Igor Gnatenko -
Kamil Dudka -
Kevin Kofler -
Nikos Mavrogiannopoulos -
Orion Poplawski -
Petr Pisar -
Remi Collet -
Tomas Mraz -
Vít Ondruch