Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

On 2018-01-11 14:32:59 [+0100], To Alessandro Ghedini wrote:
> On 2018-01-10 23:57:56 [+], Alessandro Ghedini wrote:
> > Thoughts?
> 
> If I understand Julien correctly in [0] he suggests a new soname (maybe
> with ssl suffix without bumping the 4 to 5) and a new package name.
> 
> [0] 
> https://lists.debian.org/msgid-search/b4e74ff9-6ac3-54c1-c510-34a4cfd84...@debian.org

Not that I want to rush anything or so but seems to be a RC bug with no
maintainer action > one week (or I missed it while looking through my
inbox).
Did we settle in the meantime on what we want to do? There is a merge
request on salsa with feedback from the maintainer.

Sebastian

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

On 2018-01-11 23:07:32 [+0200], Adrian Bunk wrote:
> On Thu, Jan 11, 2018 at 09:39:51PM +0100, Sebastian Andrzej Siewior wrote:
> >...
> > since everything not
> > shipped Debian wise would be suddenly linked againt libssl-1.1 while it
> > might have been compiled against an earlier version.
> 
> The handling of non-packaged software is not perfect, but there's 
> precedent for changing the package name without changing the soname 
> (e.g. check the conflicts of the libstdc++6 package in stretch).

does it mean you are pro different package name but keeping the soname?

> > Maybe it would be wise to suggest to upstream to bump major 4 to a 5 to
> > signal that this libcurl exposes the libssl1.1 ABI now.
> 
> "now" was 2016.

now was not 2016. Debian didn't have curl compiled against 1.1 shipped
anywhere. Don't know about Suse but Fedora had the same soname and
linked against nss instead of libssl [0].
- fc26 had libcurl compiled against nss [1]
- fc27 had libcurl compiled against libssl1.1 [2]

> Back then this would have been a valid point, but after other 
> distributions already ship with OpenSSL 1.1 and the old libcurl
> soname it is too late for that.

if the package maintainer agrees, he can ask upstream. Worst thing is
that they say no.

> The package name is the only thing we can change without diverging from 
> other distributions.
 
but the only reason why one wants to keep the same soname is to use
binaries from another distro/precompiled binary only code from "vendor".
Or do I miss something else?

[0] https://fedoraproject.org//wiki/Changes/libcurlBackToOpenSSL
[1] 
http://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/26/Everything/x86_64/os/Packages/l/libcurl-7.53.1-7.fc26.x86_64.rpm
[2] 
http://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/27/Everything/x86_64/os/Packages/l/libcurl-7.53.1-7.fc26.x86_64.rpm

> cu
> Adrian

Sebastian

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Adrian Bunk]

On Thu, Jan 11, 2018 at 09:39:51PM +0100, Sebastian Andrzej Siewior wrote:
>...
> since everything not
> shipped Debian wise would be suddenly linked againt libssl-1.1 while it
> might have been compiled against an earlier version.

The handling of non-packaged software is not perfect, but there's 
precedent for changing the package name without changing the soname 
(e.g. check the conflicts of the libstdc++6 package in stretch).

> Maybe it would be wise to suggest to upstream to bump major 4 to a 5 to
> signal that this libcurl exposes the libssl1.1 ABI now.

"now" was 2016.

Back then this would have been a valid point, but after other 
distributions already ship with OpenSSL 1.1 and the old libcurl
soname it is too late for that.

The package name is the only thing we can change without diverging from 
other distributions.

> Sebastian

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

On 2018-01-11 14:54:26 [+0100], Ondřej Surý wrote:
> I commented at salsa.d.o, but for consistency, I am resending my comment here:

…

> The conflict here means that all r-depends will have to migrate at once, and 
> absolutely no backports would be possible.  I wish there would be a way where 
> libcurl3 and libcurl4 would be co-installable, but so far I haven't come up 
> with anything that would make it possible and still align the packages with 
> upstream names.

You could do a proper transition and rename libcurl.so.4 to
libcurl-ssl11.so.4 and provide a symlink libcurl.so.4 ->
libcurl-ssl11.so.4 once the transition is over and the library out of
unstable. *However* this symlink is dangerous since everything not
shipped Debian wise would be suddenly linked againt libssl-1.1 while it
might have been compiled against an earlier version.
Maybe it would be wise to suggest to upstream to bump major 4 to a 5 to
signal that this libcurl exposes the libssl1.1 ABI now.

> The fact that the symbols were versioned with GNUTLS_*_3 complicates the 
> transition even more.
> 
> But I guess it's a good time to finally bite the bullet and finish the 
> transition, I just wish there would be a less intrusive way.
> 
> Ondrej

Sebastian

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Ondřej Surý]

I commented at salsa.d.o, but for consistency, I am resending my comment here:

The conflict here means that all r-depends will have to migrate at once, and 
absolutely no backports would be possible.  I wish there would be a way where 
libcurl3 and libcurl4 would be co-installable, but so far I haven't come up 
with anything that would make it possible and still align the packages with 
upstream names.

The fact that the symbols were versioned with GNUTLS_*_3 complicates the 
transition even more.

But I guess it's a good time to finally bite the bullet and finish the 
transition, I just wish there would be a less intrusive way.

Ondrej
-- 
Ondřej Surý 

On Thu, Jan 11, 2018, at 00:57, Alessandro Ghedini wrote:
> On Sun, Dec 17, 2017 at 11:16:29PM +0200, Adrian Bunk wrote:
> > On Fri, Dec 08, 2017 at 05:44:55PM +0100, Ondřej Surý wrote:
> > > Hi,
> > > 
> > > just innocent bystander here with an observation:
> > > 
> > > These two options:
> > > 
> > > a)
> > > > I do agree it's the correct solution though, and it would be a good 
> > > > opportunity
> > > > to finally sync SONAME with upstream
> > > 
> > > b)
> > > > Because of 1 I think we should change the package name (and SONAME) for
> > > > libcurl3.  I don't think 2 is appropriate.
> > > 
> > > are mutually exclusive, so even if we rename the share library packages
> > > to libcurl4*, they would have to conflict with libcurl3* because they
> > > would contain same files.
> > > 
> > > And the SONAME is already libcurl.so.4 (at least on stretch):
> > > 
> > > $ objdump -p /usr/lib/x86_64-linux-gnu/libcurl* | grep SONAME
> > >   SONAME   libcurl-gnutls.so.4
> > >   SONAME   libcurl-gnutls.so.4
> > >   SONAME   libcurl-gnutls.so.4
> > >   SONAME   libcurl.so.4
> > >   SONAME   libcurl.so.4
> > >   SONAME   libcurl.so.4
> > > 
> > > So in this case, unfortunately, bumping the SONAME is actually something
> > > different than changing package name to match to SONAME of the library. 
> > >...
> > 
> > Similar to all the v5 postfixed packages in Debian for C++ ABI changes 
> > in GCC 5, what matter here is actually not the SONAME but the package
> > name and that the new package conflicts with the old package.
> > 
> > This is sufficient to fix the issue for all packages using curl.
> > 
> > And different from breaks on specific packages, it will also force an
> > upgrade of packages from backports.
> > 
> > Non-packaged software is a different topic, but the whole OpenSSL 
> > situation in stretch is already a mess for that.
> > 
> > This whole transition looks pretty straightforward to me,
> > please let me know if there is anything where I could help.
> 
> Following Adrian's comment, I prepated a patch that:
> 
>  * Renames *all* lincurl3* packages to libcurl4* (with Conflicts+Replaces)
>  * Removes the hacks for old SONAME and updates symbols (as Ondrej correctly
>pointed out, the SONAME doesn't actually change as ww already ship a
>"libcurl.so.4", but the lib symlinks and the symbols do)
>  * Makes the OpenSSL libcurl build against OpenSSL 1.1
> 
> I think this satisfies all the requirements for the OpenSSL migration, as well
> as finally cleaning up the mess from the last botched transition as an added
> bonus.
> 
> Thoughts?
> 
> The patch is at https://salsa.debian.org/debian/curl/merge_requests/2
> 
> Cheers
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

On 2018-01-10 23:57:56 [+], Alessandro Ghedini wrote:
> > This whole transition looks pretty straightforward to me,
> > please let me know if there is anything where I could help.
> 
> Following Adrian's comment, I prepated a patch that:
> 
>  * Renames *all* lincurl3* packages to libcurl4* (with Conflicts+Replaces)
>  * Removes the hacks for old SONAME and updates symbols (as Ondrej correctly
>pointed out, the SONAME doesn't actually change as ww already ship a
>"libcurl.so.4", but the lib symlinks and the symbols do)
>  * Makes the OpenSSL libcurl build against OpenSSL 1.1
> 
> I think this satisfies all the requirements for the OpenSSL migration, as well
> as finally cleaning up the mess from the last botched transition as an added
> bonus.
> 
> Thoughts?

If I understand Julien correctly in [0] he suggests a new soname (maybe
with ssl suffix without bumping the 4 to 5) and a new package name.

[0] 
https://lists.debian.org/msgid-search/b4e74ff9-6ac3-54c1-c510-34a4cfd84...@debian.org

> The patch is at https://salsa.debian.org/debian/curl/merge_requests/2
> 
> Cheers

Sebastian

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Alessandro Ghedini]

On Sun, Dec 17, 2017 at 11:16:29PM +0200, Adrian Bunk wrote:
> On Fri, Dec 08, 2017 at 05:44:55PM +0100, Ondřej Surý wrote:
> > Hi,
> > 
> > just innocent bystander here with an observation:
> > 
> > These two options:
> > 
> > a)
> > > I do agree it's the correct solution though, and it would be a good 
> > > opportunity
> > > to finally sync SONAME with upstream
> > 
> > b)
> > > Because of 1 I think we should change the package name (and SONAME) for
> > > libcurl3.  I don't think 2 is appropriate.
> > 
> > are mutually exclusive, so even if we rename the share library packages
> > to libcurl4*, they would have to conflict with libcurl3* because they
> > would contain same files.
> > 
> > And the SONAME is already libcurl.so.4 (at least on stretch):
> > 
> > $ objdump -p /usr/lib/x86_64-linux-gnu/libcurl* | grep SONAME
> >   SONAME   libcurl-gnutls.so.4
> >   SONAME   libcurl-gnutls.so.4
> >   SONAME   libcurl-gnutls.so.4
> >   SONAME   libcurl.so.4
> >   SONAME   libcurl.so.4
> >   SONAME   libcurl.so.4
> > 
> > So in this case, unfortunately, bumping the SONAME is actually something
> > different than changing package name to match to SONAME of the library. 
> >...
> 
> Similar to all the v5 postfixed packages in Debian for C++ ABI changes 
> in GCC 5, what matter here is actually not the SONAME but the package
> name and that the new package conflicts with the old package.
> 
> This is sufficient to fix the issue for all packages using curl.
> 
> And different from breaks on specific packages, it will also force an
> upgrade of packages from backports.
> 
> Non-packaged software is a different topic, but the whole OpenSSL 
> situation in stretch is already a mess for that.
> 
> This whole transition looks pretty straightforward to me,
> please let me know if there is anything where I could help.

Following Adrian's comment, I prepated a patch that:

 * Renames *all* lincurl3* packages to libcurl4* (with Conflicts+Replaces)
 * Removes the hacks for old SONAME and updates symbols (as Ondrej correctly
   pointed out, the SONAME doesn't actually change as ww already ship a
   "libcurl.so.4", but the lib symlinks and the symbols do)
 * Makes the OpenSSL libcurl build against OpenSSL 1.1

I think this satisfies all the requirements for the OpenSSL migration, as well
as finally cleaning up the mess from the last botched transition as an added
bonus.

Thoughts?

The patch is at https://salsa.debian.org/debian/curl/merge_requests/2

Cheers


signature.asc
Description: PGP signature

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Adrian Bunk]

On Fri, Dec 08, 2017 at 05:44:55PM +0100, Ondřej Surý wrote:
> Hi,
> 
> just innocent bystander here with an observation:
> 
> These two options:
> 
> a)
> > I do agree it's the correct solution though, and it would be a good 
> > opportunity
> > to finally sync SONAME with upstream
> 
> b)
> > Because of 1 I think we should change the package name (and SONAME) for
> > libcurl3.  I don't think 2 is appropriate.
> 
> are mutually exclusive, so even if we rename the share library packages
> to libcurl4*, they would have to conflict with libcurl3* because they
> would contain same files.
> 
> And the SONAME is already libcurl.so.4 (at least on stretch):
> 
> $ objdump -p /usr/lib/x86_64-linux-gnu/libcurl* | grep SONAME
>   SONAME   libcurl-gnutls.so.4
>   SONAME   libcurl-gnutls.so.4
>   SONAME   libcurl-gnutls.so.4
>   SONAME   libcurl.so.4
>   SONAME   libcurl.so.4
>   SONAME   libcurl.so.4
> 
> So in this case, unfortunately, bumping the SONAME is actually something
> different than changing package name to match to SONAME of the library. 
>...

Similar to all the v5 postfixed packages in Debian for C++ ABI changes 
in GCC 5, what matter here is actually not the SONAME but the package
name and that the new package conflicts with the old package.

This is sufficient to fix the issue for all packages using curl.

And different from breaks on specific packages, it will also force an
upgrade of packages from backports.

Non-packaged software is a different topic, but the whole OpenSSL 
situation in stretch is already a mess for that.

This whole transition looks pretty straightforward to me,
please let me know if there is anything where I could help.

> Ondrej

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Ondřej Surý]

Hi,

just innocent bystander here with an observation:

These two options:

a)
> I do agree it's the correct solution though, and it would be a good 
> opportunity
> to finally sync SONAME with upstream

b)
> Because of 1 I think we should change the package name (and SONAME) for
> libcurl3.  I don't think 2 is appropriate.

are mutually exclusive, so even if we rename the share library packages
to libcurl4*, they would have to conflict with libcurl3* because they
would contain same files.

And the SONAME is already libcurl.so.4 (at least on stretch):

$ objdump -p /usr/lib/x86_64-linux-gnu/libcurl* | grep SONAME
  SONAME   libcurl-gnutls.so.4
  SONAME   libcurl-gnutls.so.4
  SONAME   libcurl-gnutls.so.4
  SONAME   libcurl.so.4
  SONAME   libcurl.so.4
  SONAME   libcurl.so.4

So in this case, unfortunately, bumping the SONAME is actually something
different than changing package name to match to SONAME of the library. 
Perhaps changing the package name and adding Breaks to packages using
CURLOPT_SSL_CTX_FUNCTION and adding Breaks/Replaces to libcurl3* package
might be most sane option.

On the other hand, it would be very difficult to correctly backport
newer curl (people are asking for HTTP/2 support) without bumping the
SONAME to libcurl.so.5.

Ondrej
-- 
Ondřej Surý 

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Ian Jackson]

Sebastian Andrzej Siewior writes ("Re: Bug#858398: curl: Please migrate to 
openssl1.1 in Buster"):
> On 2017-10-12 23:44:24 [+0200], To 858...@bugs.debian.org wrote:
> > this is a remainder about the openssl transition [0]. We really want to
> > remove libssl1.0-dev from unstable for Buster. I will raise the severity
> > of this bug to serious in a month. Please react before that happens.
> 
> is there anything blocking you from uploading curl with a BD against
> libssl-dev? The package builds and seems to work. It was switched to 1.0
> in Stretch because a few reverse dependecies of libcurl needed to stay
> with 1.0.

To be honest, I am not sure.  But I will try to proceed anyway.  I
will send a longer mail with a wider distribution shortly.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

On 2017-10-12 23:44:24 [+0200], To 858...@bugs.debian.org wrote:
Hi,

> this is a remainder about the openssl transition [0]. We really want to
> remove libssl1.0-dev from unstable for Buster. I will raise the severity
> of this bug to serious in a month. Please react before that happens.

is there anything blocking you from uploading curl with a BD against
libssl-dev? The package builds and seems to work. It was switched to 1.0
in Stretch because a few reverse dependecies of libcurl needed to stay
with 1.0.

Sebastian

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Hi,

this is a remainder about the openssl transition [0]. We really want to
remove libssl1.0-dev from unstable for Buster. I will raise the severity
of this bug to serious in a month. Please react before that happens.

[0] https://bugs.debian.org/871056#55

Sebastian

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: curl
Version: 7.52.1-3
Severity: important
Tags: sid buster

Please migrate to libssl-dev in the Buster cycle. It switched to 1.0 due
to #850880, #844018 but should work with 1.1 as per #828127.

Sebastian