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 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
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.
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.)
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.
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.
On 2016-10-11, Remi Collet Fedora@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
On Út, 2016-10-11 at 16:46 +0000, Petr Pisar wrote:
On 2016-10-11, Remi Collet Fedora@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.
On Tue, 2016-10-11 at 16:46 +0000, Petr Pisar wrote:
On 2016-10-11, Remi Collet Fedora@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?
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@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.
On 2016-10-12, Tomas Mraz tmraz@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
On St, 2016-10-12 at 08:21 +0000, Petr Pisar wrote:
On 2016-10-12, Tomas Mraz tmraz@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.
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.)
On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch vondruch@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@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.)
On Tue, Oct 11, 2016 at 6:08 PM, Tomas Mraz tmraz@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@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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.
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.
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.
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
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.
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.
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
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.
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.
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.)
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%C2%A0 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.)