Re: OpenSSL-1.1.0 COPR for Rawhide
On 07/25/2016 09:06 AM, Nikos Mavrogiannopoulos wrote: On Fri, 2016-07-22 at 19:11 +0200, Michael Stahl wrote: urgh, yes, that's practically guaranteed to crash LibreOffice which could pull in openssl via neon, python-stmp, postgresql-libs, openldap, curl, librdf, any gnome-vfs backend, and probably other ways i'm not aware of. As long as the symbols of both libraries are versioned, that should cause no problem (in theory). Right. The problems start once you pass an SSL * from one world to the other. This is unlikely to work as expected. Florian -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: OpenSSL-1.1.0 COPR for Rawhide
On Fri, 2016-07-22 at 19:11 +0200, Michael Stahl wrote: > On 22.07.2016 16:53, Simo Sorce wrote: > > > > On Fri, 2016-07-22 at 16:48 +0200, Tomas Mraz wrote: > > > > > > > > > 2. Add compat 1.0.2 package which would be used by 3rd party > > > applications and also temporarily by applications that are not > > > yet > > > ported to the new API. However the current plan is to not provide > > > -devel subpackage for 1.0.2 compat packages so if you needed to > > > rebuild > > > something on rawhide you would have to fix the build issues with > > > the > > > new openssl. > > > > > I am concerned about a compat package because there are a lot of > > components lining to openssl often libraries or modules, from > > different > > source RPMS. So we incur the risk of getting a binary to link with > > both > > version via modules/library dependencies and that would cause > > issues > > (probably crashes, or perhaps bad behavior) only at runtime due to > > symbol aliasing between the two versions. > > urgh, yes, that's practically guaranteed to crash LibreOffice which > could pull in openssl via neon, python-stmp, postgresql-libs, > openldap, > curl, librdf, any gnome-vfs backend, and probably other ways i'm not > aware of. As long as the symbols of both libraries are versioned, that should cause no problem (in theory). regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: OpenSSL-1.1.0 COPR for Rawhide
Michael Stahl wrote: > the only safe way to provide a compat openssl package is as a -devel > package that only contains a static library :P Even then, you need to mark all the symbols as hidden if you do not want them to get exported from shared libraries linking to it. (And of course the static library needs to be built with -fPIC or shared libraries cannot link to it to begin with.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: OpenSSL-1.1.0 COPR for Rawhide
On 22.07.2016 16:53, Simo Sorce wrote: > On Fri, 2016-07-22 at 16:48 +0200, Tomas Mraz wrote: >> >> 2. Add compat 1.0.2 package which would be used by 3rd party >> applications and also temporarily by applications that are not yet >> ported to the new API. However the current plan is to not provide >> -devel subpackage for 1.0.2 compat packages so if you needed to rebuild >> something on rawhide you would have to fix the build issues with the >> new openssl. >> > I am concerned about a compat package because there are a lot of > components lining to openssl often libraries or modules, from different > source RPMS. So we incur the risk of getting a binary to link with both > version via modules/library dependencies and that would cause issues > (probably crashes, or perhaps bad behavior) only at runtime due to > symbol aliasing between the two versions. urgh, yes, that's practically guaranteed to crash LibreOffice which could pull in openssl via neon, python-stmp, postgresql-libs, openldap, curl, librdf, any gnome-vfs backend, and probably other ways i'm not aware of. the only safe way to provide a compat openssl package is as a -devel package that only contains a static library :P -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: OpenSSL-1.1.0 COPR for Rawhide
On Fri, 2016-07-22 at 16:48 +0200, Tomas Mraz wrote: > On Pá, 2016-07-22 at 10:24 -0400, Simo Sorce wrote: > > On Fri, 2016-07-22 at 10:21 -0400, Simo Sorce wrote: > > > > > > On Fri, 2016-07-22 at 17:17 +0300, Antti Järvinen wrote: > > > > > > > > Tomas Mraz writes: > > > > > for anybody insterested in testing and/or porting applications > > > > to the > > > > > new OpenSSL 1.1.0 API I've prepared a COPR repository: > > > > > > > > Strongly advised, OpenSSL 1.1 API changes slightly compared to > > > > 1.0 and > > > > at least in debian the list of packages not compiling any more > > > > was rather > > > > impressive, see > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 > > > > and I'd expect something similar in other distributions too. > > > > Mostly > > > > this is head-ache of upstreams but it might be good manners to > > > > file > > > > upstream error tickets early :) > > > Second, I was given a heads up about failing packages by an Ubuntu > > > maintainer of upstream projects of mine, and I had to change every > > > single one of them. I haven't rebuild all of them yet for Fedora > > > either > > > because the changes do not work at run time, I have to wait until > > > Feodra > > > Rawhide gets 1.1.0 anyway. > > > > > > So please land this as early as possible in Fedora as it will > > > require to > > Actually , given how disruptive this is going to be we may want to > > think > > of creating a separate tag and rebuild the majority of core packages > > that break there and only then tag it at once in rawhide, or rawhide > > user experience will be miserable until all package maintainers get > > around to fix it. > > My current plan (might be changed) is to: > > 1. Fill Fedora Change proposal for Fedora 26 very early. > > 2. Add compat 1.0.2 package which would be used by 3rd party > applications and also temporarily by applications that are not yet > ported to the new API. However the current plan is to not provide > -devel subpackage for 1.0.2 compat packages so if you needed to rebuild > something on rawhide you would have to fix the build issues with the > new openssl. > > The tag should not be strictly necessary and I'd like to avoid it as > rawhide with the compat package should be installable and relatively > usable. Only the developers that use OpenSSL API calls would have to > patch their code. I am concerned about a compat package because there are a lot of components lining to openssl often libraries or modules, from different source RPMS. So we incur the risk of getting a binary to link with both version via modules/library dependencies and that would cause issues (probably crashes, or perhaps bad behavior) only at runtime due to symbol aliasing between the two versions. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: OpenSSL-1.1.0 COPR for Rawhide
On Pá, 2016-07-22 at 10:24 -0400, Simo Sorce wrote: > On Fri, 2016-07-22 at 10:21 -0400, Simo Sorce wrote: > > > > On Fri, 2016-07-22 at 17:17 +0300, Antti Järvinen wrote: > > > > > > Tomas Mraz writes: > > > > for anybody insterested in testing and/or porting applications > > > to the > > > > new OpenSSL 1.1.0 API I've prepared a COPR repository: > > > > > > Strongly advised, OpenSSL 1.1 API changes slightly compared to > > > 1.0 and > > > at least in debian the list of packages not compiling any more > > > was rather > > > impressive, see > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 > > > and I'd expect something similar in other distributions too. > > > Mostly > > > this is head-ache of upstreams but it might be good manners to > > > file > > > upstream error tickets early :) > > Second, I was given a heads up about failing packages by an Ubuntu > > maintainer of upstream projects of mine, and I had to change every > > single one of them. I haven't rebuild all of them yet for Fedora > > either > > because the changes do not work at run time, I have to wait until > > Feodra > > Rawhide gets 1.1.0 anyway. > > > > So please land this as early as possible in Fedora as it will > > require to > Actually , given how disruptive this is going to be we may want to > think > of creating a separate tag and rebuild the majority of core packages > that break there and only then tag it at once in rawhide, or rawhide > user experience will be miserable until all package maintainers get > around to fix it. My current plan (might be changed) is to: 1. Fill Fedora Change proposal for Fedora 26 very early. 2. Add compat 1.0.2 package which would be used by 3rd party applications and also temporarily by applications that are not yet ported to the new API. However the current plan is to not provide -devel subpackage for 1.0.2 compat packages so if you needed to rebuild something on rawhide you would have to fix the build issues with the new openssl. The tag should not be strictly necessary and I'd like to avoid it as rawhide with the compat package should be installable and relatively usable. Only the developers that use OpenSSL API calls would have to patch their code. -- 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 https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: OpenSSL-1.1.0 COPR for Rawhide
On Fri, 2016-07-22 at 10:21 -0400, Simo Sorce wrote: > On Fri, 2016-07-22 at 17:17 +0300, Antti Järvinen wrote: > > Tomas Mraz writes: > > > for anybody insterested in testing and/or porting applications to the > > > new OpenSSL 1.1.0 API I've prepared a COPR repository: > > > > Strongly advised, OpenSSL 1.1 API changes slightly compared to 1.0 and > > at least in debian the list of packages not compiling any more was rather > > impressive, see > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 > > and I'd expect something similar in other distributions too. Mostly > > this is head-ache of upstreams but it might be good manners to file > > upstream error tickets early :) > > Second, I was given a heads up about failing packages by an Ubuntu > maintainer of upstream projects of mine, and I had to change every > single one of them. I haven't rebuild all of them yet for Fedora either > because the changes do not work at run time, I have to wait until Feodra > Rawhide gets 1.1.0 anyway. > > So please land this as early as possible in Fedora as it will require to Actually , given how disruptive this is going to be we may want to think of creating a separate tag and rebuild the majority of core packages that break there and only then tag it at once in rawhide, or rawhide user experience will be miserable until all package maintainers get around to fix it. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: OpenSSL-1.1.0 COPR for Rawhide
On Fri, 2016-07-22 at 17:17 +0300, Antti Järvinen wrote: > Tomas Mraz writes: > > for anybody insterested in testing and/or porting applications to the > > new OpenSSL 1.1.0 API I've prepared a COPR repository: > > Strongly advised, OpenSSL 1.1 API changes slightly compared to 1.0 and > at least in debian the list of packages not compiling any more was rather > impressive, see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 > and I'd expect something similar in other distributions too. Mostly > this is head-ache of upstreams but it might be good manners to file > upstream error tickets early :) Second, I was given a heads up about failing packages by an Ubuntu maintainer of upstream projects of mine, and I had to change every single one of them. I haven't rebuild all of them yet for Fedora either because the changes do not work at run time, I have to wait until Feodra Rawhide gets 1.1.0 anyway. So please land this as early as possible in Fedora as it will require to rebuild *a lot* of packages. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: OpenSSL-1.1.0 COPR for Rawhide
Tomas Mraz writes: > for anybody insterested in testing and/or porting applications to the > new OpenSSL 1.1.0 API I've prepared a COPR repository: Strongly advised, OpenSSL 1.1 API changes slightly compared to 1.0 and at least in debian the list of packages not compiling any more was rather impressive, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 and I'd expect something similar in other distributions too. Mostly this is head-ache of upstreams but it might be good manners to file upstream error tickets early :) -- Antti Järvinen -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
OpenSSL-1.1.0 COPR for Rawhide
Hi, for anybody insterested in testing and/or porting applications to the new OpenSSL 1.1.0 API I've prepared a COPR repository: https://copr.fedorainfracloud.org/coprs/tmraz/OpenSSL-1.1.0/ The FIPS patches and system crypto policy patch is not yet ported. If you find any problems or have any suggestions for improvements, please mail me directly. -- 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 https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
