Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Kamil Dudka]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 08:21 +, Petr Pisar wrote:
> On 2016-10-12, Tomas Mraz  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.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Vít Ondruch]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Petr Pisar]

On 2016-10-12, Tomas Mraz  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 08:22 +0200, Nikos Mavrogiannopoulos wrote:
> On Tue, 2016-10-11 at 16:46 +, Petr Pisar wrote:
> > 
> > On 2016-10-11, Remi Collet  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.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Nikos Mavrogiannopoulos]

On Tue, 2016-10-11 at 16:46 +, Petr Pisar wrote:
> On 2016-10-11, Remi Collet  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?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[David Woodhouse]

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

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On Út, 2016-10-11 at 16:46 +, Petr Pisar wrote:
> On 2016-10-11, Remi Collet  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.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Igor Gnatenko]

On Tue, Oct 11, 2016 at 6:08 PM, Tomas Mraz  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 
>> 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-le...@lists.fedoraproject.org



-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Petr Pisar]

On 2016-10-11, Remi Collet  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On Út, 2016-10-11 at 15:27 +0200, Igor Gnatenko wrote:
> On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch 
> 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.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

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=0x1002L
> 
> Should at least partially get you the 1.0.2 API.  Although clamav's
> configure
> test for SSL_library_init() doesn't #include  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.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Orion Poplawski]

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=0x1002L

Should at least partially get you the 1.0.2 API.  Although clamav's configure
test for SSL_library_init() doesn't #include  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   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Remi Collet]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Igor Gnatenko]

On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch  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-le...@lists.fedoraproject.org



-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Vít Ondruch]

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.)
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Remi Collet]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Remi Collet]

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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[David Woodhouse]

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

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Kevin Kofler]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org