Re: OpenSSL 1.1.0

[Sean Whitton]

Hello,

On Wed, Nov 16, 2016 at 04:03:04PM +, Jonathan Wiltshire wrote:
> On 2016-11-16 12:26, Ian Jackson wrote:
> > In the absence of input from the openssl maintainers, I would like to
> > ask the Release Team's opinion.
> > 
> > If we are going to wind back on this change we should do it ASAP.  We
> > should not allow ourselves to make the decision to press on, simply by
> > failing to decide otherwise.
> 
> Indeed it's been under discussion for the past week or so independent of the
> thread on -devel. I hope you'll forgive me for not breaking confidences just
> yet, but we expect to be able to resolve this very soon.

Sorry to resurrect an old thread, but did I miss an e-mail follow-up to this?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 25 de noviembre de 2016 10:38:00 ART Stepan Golosunov wrote:
> 25.11.2016 в 02:07:11 +0100 Jan Niehusmann написал:
> > On Fri, Nov 25, 2016 at 01:56:19AM +0400, Stepan Golosunov wrote:
> > > qsslsocket_openssl_symbols.cpp also tries to load any libssl.* it can
> > > find (in directories gathered from dl_iterate_phdr) when it cannot
> > > find libssl.so..  This asks for trouble when
> > > libssl1.0.2 is not installed and probably needs to be patched out.
> > 
> > This should be covered by qt 5.7.1~20161021+dfsg-6 (currently in sid).
> > From the changelog:
> > 
> > "Make libqt5network5 depend on libssl1.0.2. It will crash when only
> > newer libssl versions are installed."
> 
> Wasn't avoiding such dependency the entire point of dlopen'ing libssl?
> If Qt can depend on libssl1.0.2 then it can probably link with it as
> well.  (And configure has option to do that, -openssl-linked.)

No, it's about the librar not linking openssl, or in other words avoiding 
libssl being listed here:

$ objdump -x /usr/lib/x86_64-linux-gnu/libQt5Network.so.5.7.1 | grep NEEDED
  NEEDED   libQt5Core.so.5
  NEEDED   libpthread.so.0
  NEEDED   libz.so.1
  NEEDED   libproxy.so.1
  NEEDED   libstdc++.so.6
  NEEDED   libc.so.6

*Packages* dependencies are then metadata about the binary, but no more than 
that.
 
> There is also an example of package that deals with a very similar
> licensing problem without using dlopen.  ffmpeg compiles a version
> that depends on libraries with more restrictive license into
> libavcodec-extra57, and a version without such dependency into
> libavcodec57.

I don't know how they handle it. I'm not sure you can avoid the problem by 
using plugins. Another way to get around this is having an app that links 
against the license-problematic lib and transfers data from and to the lib 
that requires it. In the SSl case I think that would be too much overhead to 
be usable.

-- 
6 - ¿Cuál es el botón del mouse que permite acceder a las acciones más
comunes de archivos?
a- El derecho
b- El izquierdo
c- El central
...
¿PORQUÉ no puedo ver la cara de un usuario de Macintosh?, ¿EH?
  Guillermo Marraco
  http://mx.grulic.org.ar/lurker/message/20080307.112156.460149a2.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 1.1.0

[Stepan Golosunov]

25.11.2016 в 02:07:11 +0100 Jan Niehusmann написал:
> On Fri, Nov 25, 2016 at 01:56:19AM +0400, Stepan Golosunov wrote:
> > qsslsocket_openssl_symbols.cpp also tries to load any libssl.* it can
> > find (in directories gathered from dl_iterate_phdr) when it cannot
> > find libssl.so..  This asks for trouble when
> > libssl1.0.2 is not installed and probably needs to be patched out.
> 
> This should be covered by qt 5.7.1~20161021+dfsg-6 (currently in sid).
> From the changelog:
> 
> "Make libqt5network5 depend on libssl1.0.2. It will crash when only
> newer libssl versions are installed."

Wasn't avoiding such dependency the entire point of dlopen'ing libssl?
If Qt can depend on libssl1.0.2 then it can probably link with it as
well.  (And configure has option to do that, -openssl-linked.)


There is also an example of package that deals with a very similar
licensing problem without using dlopen.  ffmpeg compiles a version
that depends on libraries with more restrictive license into
libavcodec-extra57, and a version without such dependency into
libavcodec57.

Re: OpenSSL 1.1.0

[Jan Niehusmann]

On Fri, Nov 25, 2016 at 01:56:19AM +0400, Stepan Golosunov wrote:
> qsslsocket_openssl_symbols.cpp also tries to load any libssl.* it can
> find (in directories gathered from dl_iterate_phdr) when it cannot
> find libssl.so..  This asks for trouble when
> libssl1.0.2 is not installed and probably needs to be patched out.

This should be covered by qt 5.7.1~20161021+dfsg-6 (currently in sid).
>From the changelog:

"Make libqt5network5 depend on libssl1.0.2. It will crash when only
newer libssl versions are installed."

Jan

Re: OpenSSL 1.1.0

[Stepan Golosunov]

24.11.2016 в 00:37:01 +0100 Kurt Roeckx написал:
> I've always had the impression that there are or used to be
> probems using using dlopen()/dlsym(). Maybe related to some things
> like RTDL_GLOBAL that causes the symbol lookup to go to the wrong
> library. Do you know of any problems related to that?

Some applications (asterisk) use dlsym without dlopen (with
RTLD_NEXT).  This definitely asks for trouble if there are more than
one libssl loaded.  (All of the functions dlsym'ed by Asterisk were
removed from libssl1.1 though.)

> Note that QT is one of those that uses dlopen()/dlsym() when
> calling openssl functions (for license reasons).

At least RTLD_GLOBAL (ExportExternalSymbolsHint) seems to be in
#ifdef Q_OS_OPENBSD
in qsslsocket_openssl_symbols.cpp.

qsslsocket_openssl_symbols.cpp also tries to load any libssl.* it can
find (in directories gathered from dl_iterate_phdr) when it cannot
find libssl.so..  This asks for trouble when
libssl1.0.2 is not installed and probably needs to be patched out.
(Or openssl-linked should be used.  Or Breaks: libssl1.0.0, libssl1.1
looks necessary.)

Re: OpenSSL 1.1.0

[Jan Niehusmann]

On Thu, Nov 24, 2016 at 07:23:22PM +0200, Adrian Bunk wrote:
> If both b-dev and c-dev would depend on the libssl*-dev they use,

Which is not always the case, now.

qtbase5-private-dev exposes lots of internal OpenSSL structures, but
doesn't depend on any OpenSSL package.

libcurl4-openssl-dev only suggests libssl-dev. And it provides access to
an SSL_CTX via:

typedef CURLcode (*curl_ssl_ctx_callback)(CURL *curl,/* easy handle */
  void *ssl_ctx, /* actually an
OpenSSL SSL_CTX */
  void *userptr);


It's working around a dependency by using a (void *) instead.


So, at least in theory, a package using both qtbase5-private-dev and
libcurl4-openssl-dev could relay an SSL_CTX between two different
versions of OpenSSL.

In practice, of course, its highly unlikely that a package links to two
different libraries, accesses SSL-related functions in both of them,
passes structures around, and does not depend on libssl-dev, itself.

Therefore I think this is a red herring.


The more important question is if there are any risks left if there are
no structures exchanged between the two versions of OpenSSL. Which, in
turn, boils down to the question of dlopen()/dlsym() do the right thing.

If this usage is not OK, we need to make sure no package using Qt (and,
in any of its use-cases triggering an SSL connection via Qt), links to
OpenSSL 1.1, directly or indirectly. And indirect usage can't be
prevented with the build-dependency Adrian suggests.

If, instead, such usage is fine, only (dev-)packages exposing SSL
structures need to be protected by a build-dependency on libssl-dev.
That would be libcurl4-openssl-dev, qtbase5-private-dev and probably
some others I don't know about.

Jan

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Thu, Nov 24, 2016 at 02:50:23PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 24 Nov 2016, Adrian Bunk wrote:
> > On Wed, Nov 23, 2016 at 11:50:12PM -0200, Henrique de Moraes Holschuh wrote:
> > > On Thu, 24 Nov 2016, Kurt Roeckx wrote:
> > >...
> > > > > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> > > > > might not be safe.   If it doesn't (i.e. at most you have a qt flag 
> > > > > that
> > > > > says "use SSL", etc), then it should be fine.
> > > > 
> > > > It seems to be doing this in qtbase5-private-dev. Not sure if
> > > > there are actually any users of it.
> > > 
> > > If it does, all reverse *build* dependencies would need to be inspected,
> > > then.
> > > 
> > > AFAIK, that means they must not link to anything that could link to a
> > > different libssl than the one used by qt5.  If they do, everything needs
> > > to be inspected down to the details to ensure nothing will ever leak
> > > openssl contextes and data structures across a library boundary
> > > (including the application).
> > 
> > If inspection is not easily possible, then adding a dependency on 
> > libssl1.0-dev to qtbase5-private-dev should be sufficient to
> > ensure that this is not leaked to a different OpenSSL version.
> 
> How so? 
> 
> Consider the flattened tree (app is the root, - denotes a branch).
> 
> A - B - App -  C - D
> 
> Where A and D are two versions of openssl. B and C are libs (suppose B
> comes from qtbase5-private-dev) from different source packages.

Where does App get the definitions/declarations for the contextes and 
data structures it could leak between A and D?

If they are part of the B API and part of the C API, then they are used 
in the header files shipped in b-dev and c-dev.

If both b-dev and c-dev would depend on the libssl*-dev they use,
then App cannot be compiled with both B and C unless these use
the same OpenSSL. Any mismatch would very quickly be reported
as a FTBFS bug.

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

Re: OpenSSL 1.1.0

[Henrique de Moraes Holschuh]

On Thu, 24 Nov 2016, Adrian Bunk wrote:
> On Wed, Nov 23, 2016 at 11:50:12PM -0200, Henrique de Moraes Holschuh wrote:
> > On Thu, 24 Nov 2016, Kurt Roeckx wrote:
> >...
> > > > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> > > > might not be safe.   If it doesn't (i.e. at most you have a qt flag that
> > > > says "use SSL", etc), then it should be fine.
> > > 
> > > It seems to be doing this in qtbase5-private-dev. Not sure if
> > > there are actually any users of it.
> > 
> > If it does, all reverse *build* dependencies would need to be inspected,
> > then.
> > 
> > AFAIK, that means they must not link to anything that could link to a
> > different libssl than the one used by qt5.  If they do, everything needs
> > to be inspected down to the details to ensure nothing will ever leak
> > openssl contextes and data structures across a library boundary
> > (including the application).
> 
> If inspection is not easily possible, then adding a dependency on 
> libssl1.0-dev to qtbase5-private-dev should be sufficient to
> ensure that this is not leaked to a different OpenSSL version.

How so? 

Consider the flattened tree (app is the root, - denotes a branch).

A - B - App -  C - D

Where A and D are two versions of openssl. B and C are libs (suppose B
comes from qtbase5-private-dev) from different source packages.

-- 
  Henrique Holschuh

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Thu, Nov 24, 2016 at 03:20:06PM +0100, Jan Niehusmann wrote:
> On Thu, Nov 24, 2016 at 03:59:10PM +0200, Adrian Bunk wrote:
> > If inspection is not easily possible, then adding a dependency on 
> > libssl1.0-dev to qtbase5-private-dev should be sufficient to
> > ensure that this is not leaked to a different OpenSSL version.
> 
> I see two disadvantages:
> 
> 1) doesn't catch cases where a package doesn't depend on libssl at all,
>but depends on two libraries which in turn use qt and libssl.
>...

I was answering to the "exposes OpenSSL internels (e.g. opaque structs)
in its API" problem.

When every -dev that contains headers exposing OpenSSL internals depends 
on the libssl*-dev it uses, then this problem is solved.

dlopen() is a separate problem.

> But I don't know a better alternative, either.
> 
> Jan

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

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On jueves, 24 de noviembre de 2016 15:20:06 ART Jan Niehusmann wrote:
> On Thu, Nov 24, 2016 at 03:59:10PM +0200, Adrian Bunk wrote:
> > If inspection is not easily possible, then adding a dependency on
> > libssl1.0-dev to qtbase5-private-dev should be sufficient to
> > ensure that this is not leaked to a different OpenSSL version.
> 
> I see two disadvantages:
> 
> 1) doesn't catch cases where a package doesn't depend on libssl at all,
>but depends on two libraries which in turn use qt and libssl.
> 
> 2) needlessly affects packages which use qt, but don't use QNetwork /
>QSsl.

Right, that's exactly why we didn't went for this approach.


-- 
firmaware: soft cuya licencia pagas enviando un autografo
  StucKman en #grulic, irc.freenode.net

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 1.1.0

[Jan Niehusmann]

On Thu, Nov 24, 2016 at 03:59:10PM +0200, Adrian Bunk wrote:
> If inspection is not easily possible, then adding a dependency on 
> libssl1.0-dev to qtbase5-private-dev should be sufficient to
> ensure that this is not leaked to a different OpenSSL version.

I see two disadvantages:

1) doesn't catch cases where a package doesn't depend on libssl at all,
   but depends on two libraries which in turn use qt and libssl.

2) needlessly affects packages which use qt, but don't use QNetwork /
   QSsl.

But I don't know a better alternative, either.

Jan

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Wed, Nov 23, 2016 at 11:50:12PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 24 Nov 2016, Kurt Roeckx wrote:
>...
> > > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> > > might not be safe.   If it doesn't (i.e. at most you have a qt flag that
> > > says "use SSL", etc), then it should be fine.
> > 
> > It seems to be doing this in qtbase5-private-dev. Not sure if
> > there are actually any users of it.
> 
> If it does, all reverse *build* dependencies would need to be inspected,
> then.
> 
> AFAIK, that means they must not link to anything that could link to a
> different libssl than the one used by qt5.  If they do, everything needs
> to be inspected down to the details to ensure nothing will ever leak
> openssl contextes and data structures across a library boundary
> (including the application).

If inspection is not easily possible, then adding a dependency on 
libssl1.0-dev to qtbase5-private-dev should be sufficient to
ensure that this is not leaked to a different OpenSSL version.

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

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On jueves, 24 de noviembre de 2016 00:37:01 ART Kurt Roeckx wrote:
[snip] 
> > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> > might not be safe.   If it doesn't (i.e. at most you have a qt flag that
> > says "use SSL", etc), then it should be fine.
> 
> It seems to be doing this in qtbase5-private-dev. Not sure if
> there are actually any users of it.

Sadly there are users of qtbase5-private-dev, and that's why we need to do a 
transition on each patch release. Ugly as hell, but nothying we maintainers 
can do about it.

Now which of those use the SSL stuff is another thing which I would really not 
try to dig into.

-- 
The POP3 server service depends on the SMTP server service, which
failed to start because of the following error:
The operation completed successfully.
  -- Windows NT Server v3.51

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 1.1.0

[Henrique de Moraes Holschuh]

On Thu, 24 Nov 2016, Kurt Roeckx wrote:
> I've always had the impression that there are or used to be
> probems using using dlopen()/dlsym(). Maybe related to some things
> like RTDL_GLOBAL that causes the symbol lookup to go to the wrong
> library. Do you know of any problems related to that?

AFAIK, OpenSSL itself -- at least as packaged by Debian -- should not
get confused about where its *own* static globals are.  And any globals
it might export would also be fully ELF-symbol-versioned from what I can
see (objdump -tT).

If RTDL_GLOBAL is borking ELF symbol versioning, all bets are off.

Note: I have no idea what happens if you throw libssl.a into the mix
with a different version of libssl.so.  This kind of hell-born
braindamage can happen due to glibc nss modules, for example.

> Note that QT is one of those that uses dlopen()/dlsym() when
> calling openssl functions (for license reasons).

No comment I could make about this would be acceptable in polite
company.  Or in impolite company.  Or even during a sailor-class-cursing
competition.

> > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> > might not be safe.   If it doesn't (i.e. at most you have a qt flag that
> > says "use SSL", etc), then it should be fine.
> 
> It seems to be doing this in qtbase5-private-dev. Not sure if
> there are actually any users of it.

If it does, all reverse *build* dependencies would need to be inspected,
then.

AFAIK, that means they must not link to anything that could link to a
different libssl than the one used by qt5.  If they do, everything needs
to be inspected down to the details to ensure nothing will ever leak
openssl contextes and data structures across a library boundary
(including the application).

-- 
  Henrique Holschuh

Re: OpenSSL 1.1.0

[Kurt Roeckx]

On Mon, Nov 21, 2016 at 11:30:13AM -0200, Henrique de Moraes Holschuh wrote:
> On Mon, Nov 21, 2016, at 11:06, Jan Niehusmann wrote:
> > On Mon, Nov 21, 2016 at 11:11:09AM +0100, Tino Mettler wrote:
> > > At the end I noticed that Qt will stay at 1.0 (by glancing into the
> > > changelog of the relevant upload) which means that my package also has
> > > to to stay at 1.0 and the whole excitement resulted in just a changed
> > > build-dep.
> > 
> > I'm not so sure about this any more:
> > 
> > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
> > Golosunov wrote that according to his understanding of dlsym(3), it
> > should be fine to link a program with OpenSSL 1.1 and Qt at the same
> > time, even though Qt links to OpenSSL 1.0.
> > 
> > Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
> > that?
> 
> The linking is fine, I believe even any eventual globals (if any) will
> be correctly handled in Debian nowadays.  What causes extremely nasty
> issues is layering violations causing openssl data structures to leak
> from something linked to one version of the library, to something else
> linked to another version of the library.
> 
>  If, at any point, internal data structures from openssl are exposed, or
>  OpenSSL contextes are passed between two libraries, or a library and an
>  application, *they must all be from the same openssl*.
> 
> This is not something the linker or dlopen/dlsym can enforce.  And you
> need to manually inspect the code to be sure... usually.

I've always had the impression that there are or used to be
probems using using dlopen()/dlsym(). Maybe related to some things
like RTDL_GLOBAL that causes the symbol lookup to go to the wrong
library. Do you know of any problems related to that?

Note that QT is one of those that uses dlopen()/dlsym() when
calling openssl functions (for license reasons).

> So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> might not be safe.   If it doesn't (i.e. at most you have a qt flag that
> says "use SSL", etc), then it should be fine.

It seems to be doing this in qtbase5-private-dev. Not sure if
there are actually any users of it.


Kurt

Re: OpenSSL 1.1.0

[Antti Järvinen]

Henrique de Moraes Holschuh writes:
 > The linking is fine, I believe even any eventual globals (if any) will
 > be correctly handled in Debian nowadays.  What causes extremely nasty

Someone confirm following is true: both application using 1.1 and
library (qt in my example) using 1.0 both create encryption keys, both
first call function RAND_seed(..) then is the random pool properly
initialized for both versions of the library?? I haven't looked at
internals but his kind of random pool might be easily implemented as a
global shared object. Or a separate one. Initializing the correct one
could be tricky at run-time. 

--
Antti

Re: OpenSSL 1.1.0

[Russ Allbery]

Bernd Zeimetz  writes:
> On 11/21/2016 03:35 AM, Clint Adams wrote:
>> On Sun, Nov 20, 2016 at 01:57:52PM +0100, Marco d'Itri wrote:

>>> I do not think that anybody has been considering GnuTLS as a credible 
>>> replacement for a very long time.

>> That's very silly.

> No, its the truth unfortunately.

It's a ton of work to maintain a high-quality SSL implementation.  Even
apart from the multitude of security issues that constantly arise, you
have to deal with interoperability with a bunch of half-assed, semi-broken
SSL implementations in the wild.  It needs resources, and the GnuTLS
development team doesn't seem to have those resources (and hasn't for a
while).  This in turn makes it hard to persuade upstreams to even consider
it, since they're usually very worried about interopability (and GnuTLS
has a spotty track record there).

It also really hurts for GnuTLS to have a completely different API,
whatever the merits of that API over OpenSSL's.  (The OpenSSL
compatibility layer is missing so much that it's not really usable.  For
instance, it offers no way to set cipher suite preferences at all and
disables TLSv1.1 and newer, at least as far as I was able to determine
from looking at the code while trying to solve another reported bug.)

-- 
Russ Allbery (r...@debian.org)   

Re: OpenSSL 1.1.0

[Bernd Zeimetz]

On 11/21/2016 03:35 AM, Clint Adams wrote:
> On Sun, Nov 20, 2016 at 01:57:52PM +0100, Marco d'Itri wrote:
>> I do not think that anybody has been considering GnuTLS as a credible 
>> replacement for a very long time.
> 
> That's very silly.

No, its the truth unfortunately.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 11:30:13 ART Henrique de Moraes Holschuh 
wrote:
> On Mon, Nov 21, 2016, at 11:06, Jan Niehusmann wrote:
> > On Mon, Nov 21, 2016 at 11:11:09AM +0100, Tino Mettler wrote:
> > > At the end I noticed that Qt will stay at 1.0 (by glancing into the
> > > changelog of the relevant upload) which means that my package also has
> > > to to stay at 1.0 and the whole excitement resulted in just a changed
> > > build-dep.
> > 
> > I'm not so sure about this any more:
> > 
> > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
> > Golosunov wrote that according to his understanding of dlsym(3), it
> > should be fine to link a program with OpenSSL 1.1 and Qt at the same
> > time, even though Qt links to OpenSSL 1.0.
> > 
> > Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
> > that?
> 
> The linking is fine, I believe even any eventual globals (if any) will
> be correctly handled in Debian nowadays.  What causes extremely nasty
> issues is layering violations causing openssl data structures to leak
> from something linked to one version of the library, to something else
> linked to another version of the library.
> 
>  If, at any point, internal data structures from openssl are exposed, or
>  OpenSSL contextes are passed between two libraries, or a library and an
>  application, *they must all be from the same openssl*.
> 
> This is not something the linker or dlopen/dlsym can enforce.  And you
> need to manually inspect the code to be sure... usually.
> 
> So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> might not be safe.   If it doesn't (i.e. at most you have a qt flag that
> says "use SSL", etc), then it should be fine.

Qt uses ssl in QtNetwork, so at very least I would say that if you don't use 
QtNetwork you should be fine.

But this is only theory.

-- 
Bebe a bordo (pero con moderación)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 1.1.0

[Henrique de Moraes Holschuh]

On Mon, Nov 21, 2016, at 11:06, Jan Niehusmann wrote:
> On Mon, Nov 21, 2016 at 11:11:09AM +0100, Tino Mettler wrote:
> > At the end I noticed that Qt will stay at 1.0 (by glancing into the
> > changelog of the relevant upload) which means that my package also has
> > to to stay at 1.0 and the whole excitement resulted in just a changed
> > build-dep.
> 
> I'm not so sure about this any more:
> 
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
> Golosunov wrote that according to his understanding of dlsym(3), it
> should be fine to link a program with OpenSSL 1.1 and Qt at the same
> time, even though Qt links to OpenSSL 1.0.
> 
> Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
> that?

The linking is fine, I believe even any eventual globals (if any) will
be correctly handled in Debian nowadays.  What causes extremely nasty
issues is layering violations causing openssl data structures to leak
from something linked to one version of the library, to something else
linked to another version of the library.

 If, at any point, internal data structures from openssl are exposed, or
 OpenSSL contextes are passed between two libraries, or a library and an
 application, *they must all be from the same openssl*.

This is not something the linker or dlopen/dlsym can enforce.  And you
need to manually inspect the code to be sure... usually.

So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
might not be safe.   If it doesn't (i.e. at most you have a qt flag that
says "use SSL", etc), then it should be fine.

-- 
  Henrique de Moraes Holschuh 

Re: OpenSSL 1.1.0

[Jan Niehusmann]

Hi,

On Mon, Nov 21, 2016 at 11:11:09AM +0100, Tino Mettler wrote:
> At the end I noticed that Qt will stay at 1.0 (by glancing into the
> changelog of the relevant upload) which means that my package also has
> to to stay at 1.0 and the whole excitement resulted in just a changed
> build-dep.

I'm not so sure about this any more:

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
Golosunov wrote that according to his understanding of dlsym(3), it
should be fine to link a program with OpenSSL 1.1 and Qt at the same
time, even though Qt links to OpenSSL 1.0.

Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
that?

If that's true, it would (IMHO) be a major step towards a timely release
of stretch with OpenSSL 1.1 as the default version.

Jan

Re: OpenSSL 1.1.0

[Tino Mettler]

On Thu, Nov 17, 2016 at 13:10:40 +0200, Adrian Bunk wrote:

[...]

> Is everyone aware that this choice is per-cluster and not per-package?

Hi,

one of my packages uses OpenSSL and Qt.  I tried to inform upstream
regarding the plans for 1.1 in Stretch because the package FTBFS with
1.1 as it uses a lot of structures that got opaque (which requires some
non-trivial changes).  It wasn't that easy to get the current state and
plans for the transition when digging in bug reports, changelogs,
mailing lists and helpful hints I got on IRC by accident.

At the end I noticed that Qt will stay at 1.0 (by glancing into the
changelog of the relevant upload) which means that my package also has
to to stay at 1.0 and the whole excitement resulted in just a changed
build-dep.

I was somewhat puzzled that I did not read anything about the whole
subject at debian-devel-announce, as it is not one of the usual
transitions.

Regards,
Tino

Re: OpenSSL 1.1.0

[Scott Kitterman]

On Sunday, November 20, 2016 12:49:13 AM Kurt Roeckx wrote:
> On Sat, Nov 19, 2016 at 10:32:58PM +0100, Ondrej Novy wrote:
> > Hi,
> > 
> > 2016-11-19 21:06 GMT+01:00 Kurt Roeckx :
> > > Chacha20 would be a new feature. Following the policy that can't
> > > be added in a 1.0.2 version, only bugs get fixed in it.
> > 
> > yep, they don't add new feature, but break API between 1.1.0b->c  release:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844366
> > https://github.com/openssl/openssl/issues/1903
> 
> This is being fixed.

Great.  Would it be possible to revert this change in Debian for now so that 
1.1.0 can get to Testing and stop blocking other changes that have been built 
against openssl 1.1?  I have a package on the autoremoval list that can't get 
to Testing until it does.  I know I can periodically comment on the bug in 
question, but it'd be nicer just to have the fix migrate.

Scott K

Re: OpenSSL 1.1.0

[Clint Adams]

On Sun, Nov 20, 2016 at 01:57:52PM +0100, Marco d'Itri wrote:
> I do not think that anybody has been considering GnuTLS as a credible 
> replacement for a very long time.

That's very silly.

Re: OpenSSL 1.1.0

[Moritz Mühlenhoff]

Adrian Bunk  schrieb:
> Supporting 1.0.2 only [1] plus chacha20 patched into that - it is not 
> obvious to me why this would be that much worse in comparison that
> it would not be an option under any circumstances.

That patch has never been upstreamed and is not something we can
rely on, it's also questionable whether it will receive any support
from its author(s). I very much doubt cloudflare will use it much
longer.

Cheers,
Moritz

Re: OpenSSL 1.1.0

[Moritz Mühlenhoff]

Stefan Fritsch  schrieb:
> On Friday, 18 November 2016 22:22:59 CET Moritz Mühlenhoff wrote:
>> Adrian Bunk  schrieb:
>> > And/or get sponsorship from companies for supporting ChaCha20-patched
>> > 1.0.2
>> 
>> It's not a matter of whipping up some patch; anything less than an
>> official backport of chacha20 into a 1.0.2x release is not going
>> to be supportable.
>
> I am sure Redhat will be interested in that as well. So release now with 
> 1.0.2 
> without ChaCha20 and upgrade openssl in a point release when/if 1.0.2 
> supports 
> ChaCha20.

Red Hat has no product with long term support based on 1.0.2 and RHEL 8 will
certainly use 1.1, so while that would certainly be great I'm afraid such a
patch is hypothetical.

Cheers,
   Moritz

Re: OpenSSL 1.1.0

[Marco d'Itri]

On Nov 19, Simon Richter  wrote:

> My dream solution at this point would be to organize a week-long
> hackfest somewhere where we move everything to GnuTLS if possible.
I do not think that anybody has been considering GnuTLS as a credible 
replacement for a very long time.
A few years ago Red Hat started porting some major packages to NSS, but 
even this effort has been discontined: 
https://fedoraproject.org/wiki/FedoraCryptoConsolidation .

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: OpenSSL 1.1.0

[Bernd Zeimetz]

On 11/19/2016 11:59 PM, Simon Richter wrote:

> My dream solution at this point would be to organize a week-long
> hackfest somewhere where we move everything to GnuTLS if possible.

Are you sure that makes things better? I've seen too many weird issues
with GnuTLS. What about LibreSSL?


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: OpenSSL 1.1.0

[Kurt Roeckx]

On Sat, Nov 19, 2016 at 10:32:58PM +0100, Ondrej Novy wrote:
> Hi,
> 
> 2016-11-19 21:06 GMT+01:00 Kurt Roeckx :
> 
> > Chacha20 would be a new feature. Following the policy that can't
> > be added in a 1.0.2 version, only bugs get fixed in it.
> >
> 
> yep, they don't add new feature, but break API between 1.1.0b->c  release:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844366
> https://github.com/openssl/openssl/issues/1903

This is being fixed.


Kurt

Re: OpenSSL 1.1.0

[Simon Richter]

Hi,

On 19.11.2016 23:07, Marco d'Itri wrote:

>> plugin messes with those internals. For example, for apache2 there is 
>> gridsite 
>> which uses mod_ssl private interfaces and a private copy of a header from 
>> the 
>> apache2 sources to get access to the SSL context. Finding all such issues in 
>> all packages will take time.

> We call this "broken by design" and a "FPOS program".

The problem with OpenSSL is that these things are often necessary.

In KiCad, we explicitly link against OpenSSL in order to initialize a
struct that contains lock/unlock functions, in case the libcurl we use
is linked against OpenSSL, so it doesn't keel over when asked to perform
two HTTPS requests at the same time.

The git history of OpenSSL doesn't exactly give me a lot of confidence
either, and stable branches are apparently not even compile tested after
backporting fixes (as evidenced by compile failures on KiCad's Jenkins
server).

My dream solution at this point would be to organize a week-long
hackfest somewhere where we move everything to GnuTLS if possible.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: OpenSSL 1.1.0

[Marco d'Itri]

On Nov 19, Stefan Fritsch  wrote:

> plugin messes with those internals. For example, for apache2 there is 
> gridsite 
> which uses mod_ssl private interfaces and a private copy of a header from the 
> apache2 sources to get access to the SSL context. Finding all such issues in 
> all packages will take time.
We call this "broken by design" and a "FPOS program".

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: OpenSSL 1.1.0

[Ondrej Novy]

Hi,

2016-11-19 21:06 GMT+01:00 Kurt Roeckx :

> Chacha20 would be a new feature. Following the policy that can't
> be added in a 1.0.2 version, only bugs get fixed in it.
>

yep, they don't add new feature, but break API between 1.1.0b->c  release:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844366
https://github.com/openssl/openssl/issues/1903
https://github.com/openssl/openssl/commit/4880672a9b41a09a0984b55e219f02a2de7ab75e

Really nice.

Please revert this transition and try again with buster, thanks.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: OpenSSL 1.1.0

[Kurt Roeckx]

On Sat, Nov 19, 2016 at 06:30:06PM +0100, Bernd Zeimetz wrote:
> On 11/17/2016 12:40 AM, Kurt Roeckx wrote:
> > On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote:
> >>
> >> The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
> >> but that sort of assumes that you are only interested in openssl 1.1 for
> >> ChaCha20 (and not the other changes).
> > 
> > I'm not willing to maintain such a patch.
> 
> Understandable. Did you talk to upstream about the issue? What do they say?

Chacha20 would be a new feature. Following the policy that can't
be added in a 1.0.2 version, only bugs get fixed in it.

We made a new release with new features, that version is 1.1.0.


Kurt

Re: OpenSSL 1.1.0

[Bernd Zeimetz]

On 11/17/2016 12:40 AM, Kurt Roeckx wrote:
> On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote:
>>
>> The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
>> but that sort of assumes that you are only interested in openssl 1.1 for
>> ChaCha20 (and not the other changes).
> 
> I'm not willing to maintain such a patch.

Understandable. Did you talk to upstream about the issue? What do they say?


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: OpenSSL 1.1.0

[Stefan Fritsch]

On Friday, 18 November 2016 22:22:59 CET Moritz Mühlenhoff wrote:
> Adrian Bunk  schrieb:
> > And/or get sponsorship from companies for supporting ChaCha20-patched
> > 1.0.2
> 
> It's not a matter of whipping up some patch; anything less than an
> official backport of chacha20 into a 1.0.2x release is not going
> to be supportable.

I am sure Redhat will be interested in that as well. So release now with 1.0.2 
without ChaCha20 and upgrade openssl in a point release when/if 1.0.2 supports 
ChaCha20.

That or delay the release by a few months.

BTW, just because an openssl-using app/lib does not export an interface that 
allows access of openssl-related internals does not mean that no other lib or 
plugin messes with those internals. For example, for apache2 there is gridsite 
which uses mod_ssl private interfaces and a private copy of a header from the 
apache2 sources to get access to the SSL context. Finding all such issues in 
all packages will take time.

Cheers,
Stefan

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Fri, Nov 18, 2016 at 10:22:59PM +0100, Moritz Mühlenhoff wrote:
> Adrian Bunk  schrieb:
> > And/or get sponsorship from companies for supporting ChaCha20-patched 
> > 1.0.2
> 
> It's not a matter of whipping up some patch; anything less than an
> official backport of chacha20 into a 1.0.2x release is not going
> to be supportable.

Supporting 1.1.0 in addition to 1.0.2, including 2 years of supporting 
1.1.0 after upstream support for it ended - it is confirmed that Debian
is able and willing to support that.

Supporting 1.0.2 only [1] plus chacha20 patched into that - it is not 
obvious to me why this would be that much worse in comparison that
it would not be an option under any circumstances.

Whether it is the best available option is a separate question.

My current preference would be stretch 1.0.2-only[2], and an early 
buster a year later[3] if Fedora manages to make a release with 1.1
in June.

With dual 1.0.2/1.1 not working in the current release schedule,
what is your preferred solution?

> Cheers,
> Moritz

cu
Adrian

[1] which should see a lot less code changes now that upstream
is focussing on 1.1 and later
[2] with or without ChaCha20 patched
[3] my preference, whether the release team would agree I do not know

-- 

   "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

Re: OpenSSL 1.1.0

[Moritz Mühlenhoff]

Adrian Bunk  schrieb:
> And/or get sponsorship from companies for supporting ChaCha20-patched 
> 1.0.2

It's not a matter of whipping up some patch; anything less than an
official backport of chacha20 into a 1.0.2x release is not going
to be supportable.

Cheers,
Moritz

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Thu, Nov 17, 2016 at 10:43:53PM +0100, Moritz Mühlenhoff wrote:
> Adrian Bunk  schrieb:
> > On Tue, Nov 15, 2016 at 09:37:01AM -0300, Lisandro Damián Nicanor Pérez 
> > Meyer wrote:
> >> On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote:
> >> > On Nov 14, Lisandro Damián Nicanor Pérez Meyer  
> >> > wrote:
> >> > > And yes, I would step back and switch libssl-dev to provide 
> >> > > libssl1.0-dev
> >> > > and have libssl1.1-dev around for anyone who can really do the switch.
> >> > I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
> >> > bad default for next year's release.
> >> > Bad enough that I would have to use a different distribution for some
> >> > web servers.
> >> 
> >> That's why I wrote:
> >> 
> >>   And if we **really** need to switch to libssl1.1 then we **really** need 
> >> to
> >>   delay the release by 6 months as a very minimum, maybe 1 year.
> >> 
> >> Yes, I also know that it sounds awful, but do we have another way out?
> >
> > Yes, patching the OpenSSL 1.1 features that are really needed into the
> > Debian OpenSSL 1.0.2 package.
> >
> > For ChaCha20 that's existing patches that are already being used
> > elsewhere.
> 
> That's not an option, while there's an external patch for chacha20/poly
> by cloudflare it hasn't been upstreamed and we cannot cover it with
> security support in a meaningful manner.

1.1.0 will be out of upstream security support after August 2018,
1.0.2 after 2019.

Debian is able and willing to provide security support for two OpenSSL 
releases in stretch, that will both be without upstream support in 2020.

> And other features are not
> backportable at all.
> 
> Kurt has already asked who would do the backports and support them in
> https://lists.debian.org/debian-release/2016/10/msg00609.html, so stop
> pretending that's a genuine option.

Dual 1.0.2/1.1 is the expected mess, and people have to stop pretending 
it would be a genuine option that most of the important packages in 
stretch would use 1.1, unless the release schedule is moved by 6-12 
months.

Trying to make all or a majority of OpenSSL-using packages in stretch 
use 1.1 might not even be much faster in delivering 1.1 features to
stable users than making stretch 1.0.2-only[1], and release buster
1.1-only a year after stretch.

As a bonus, "stretch 1.0.2-only and early buster" would imply providing 
security support for one OpenSSL version that will be upstream-supported 
during the whole (non-LTS) lifetime of stretch, instead of providing 
security support for two OpenSSL versions that will both get out of 
upstream support during the lifetime of a stretch without early buster.

And/or get sponsorship from companies for supporting ChaCha20-patched 
1.0.2 through Freexian - this would be an option that would not impact 
the release schedule.[2]

OpenSSL upstream created this mess by only providing new features 
together with a huge API breakage, and there are no nice solutions
for stretch.

cu
Adrian

[1] shipping 1.1 as security-supported technology preview is an option
[2] I am aware that this would be controversial

-- 

   "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

Re: OpenSSL 1.1.0

[Moritz Mühlenhoff]

Adrian Bunk  schrieb:
> On Tue, Nov 15, 2016 at 09:37:01AM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
>> On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote:
>> > On Nov 14, Lisandro Damián Nicanor Pérez Meyer  
>> > wrote:
>> > > And yes, I would step back and switch libssl-dev to provide libssl1.0-dev
>> > > and have libssl1.1-dev around for anyone who can really do the switch.
>> > I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
>> > bad default for next year's release.
>> > Bad enough that I would have to use a different distribution for some
>> > web servers.
>> 
>> That's why I wrote:
>> 
>>   And if we **really** need to switch to libssl1.1 then we **really** need to
>>   delay the release by 6 months as a very minimum, maybe 1 year.
>> 
>> Yes, I also know that it sounds awful, but do we have another way out?
>
> Yes, patching the OpenSSL 1.1 features that are really needed into the
> Debian OpenSSL 1.0.2 package.
>
> For ChaCha20 that's existing patches that are already being used
> elsewhere.

That's not an option, while there's an external patch for chacha20/poly
by cloudflare it hasn't been upstreamed and we cannot cover it with
security support in a meaningful manner. And other features are not
backportable at all.

Kurt has already asked who would do the backports and support them in
https://lists.debian.org/debian-release/2016/10/msg00609.html, so stop
pretending that's a genuine option.

Re: OpenSSL 1.1.0

[Bernd Zeimetz]

Hi,

> 
> OpenSSL 1.0 + 1.1
> ==
> 
> * Every package will be buildable but we can expect surprises on
> runtime due to dlopen'ed libraries, indirect use, etc
> * Release delay seems certain but difficult to determine
> * Even with a release delay, we cannot be 100% sure all the rutnime
> surprises will be gone
> * We need to support 2 versions of OpenSSL and be prepared for
> third-party applications (not included with Debian) to fail due to
> runtime surprises
> * Different support cycles upstream (one LTSL, one not)
> * We will be providing both versions of OpenSSL for the end-user to
> choose (when he has the knowledge)

I think releasing with 1.0+1.1 makes sense, but without forcing 1.1 to
be the default. Single packages which support 1.1 very well should be
able to use it, but maintainers should not be forced to even try to
migrate to a new version.

This would even make it possible to backport packages to support the new
OpenSSL version. Maybe even apache2. In the meantime people could use
haproxy in front of it, or whatever else they like.

Having ChaCha20 is nice, but delaying a release for it is not an option
(hint: people won't be able to use ChaCha20 while they are waiting for a
release... :))


best regards,

Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Wed, Nov 16, 2016 at 10:53:18PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-16 19:49:44 [+0200], Adrian Bunk wrote:
> > The problem are not specific bugs, the problem is the whole size of the
> > problem:
> > 
> > 1. Sorting out what packages have to stay at 1.0.2
> > The majority of OpenSSL-using packages in stretch might end up 
> > using 1.0.2 - sorting this out is part of the ongoing OpenSSL
> > transition.
> 
> You have two choices: either port it to 1.1.0 and stay with 1.0.2.

60 packages got removed from testing since there was only a 10 day
window between openssl1.0 being available and autoremoval of these
packages.

And after submitting patches to switch packages to 1.0.2, it was you who 
said "Adrian, seriously? This is not a patch."

This is your transition, and it should actually be you who is working on 
getting all ~ 200 RC bugs in sid related to your transition resolved.

And this is only about the simple cases.
A huge problem is the unknown number of small and big clusters of 
packages that have to use the same OpenSSL version.

Noone from you OpenSSL developers seems to be working on sorting these 
clusters out.

Like I do not understand why Kurt is trying to switch Apache to 1.1
As far as I can see, Apache is part of the libcurl3 cluster where
all packages anyway have to stay at 1.0.2 for stretch.

> > 2. OpenSSL 1.1 support is often only build-tested
> > We are currently at 650 packages in unstable depending on libssl1.0.2, 
> > and when binNMUs will happen we might get a three-digit number of
> > new RC bugs like #843988 and #843532.
> 
> stunnel was prepared upstream to work with 1.1.0 and it wasn't perfect.
> We would also face the same problem if openssl 1.0.2 decided to do a
> realloc() at some point. Lucky it did not yet.
>...

Every non-trivial piece of software has bugs.

The relevant part here is "works with 1.0.2, but did not work with 1.1".
These are regressions when switching from 1.0.2 to 1.1, no matter where
the actual bug is.

> > 3. Another Debian OpenSSL security fiasco?
> > Bugs like #843988 are only about problems that show up immediately.
> > This is often code where mistakes can be CVEs, and bug #843988 or
> > the comment "With Kurt's patch, apache2 crashes on startup" don't
> > make me optimistic regarding silent new security holes.
> > Depending on how/if this was applied upstream, these might become
> > Debian-specific CVEs.
> 
> I forwaded (or tried) my 1.1.0 fixups to upstream. I didn't find alive
> upstream for the two perl patches I made and had hope that the debian
> maintainer knows how to forwarded them.

You are not the only one patching these, and surely not the least
knowledgable person making such patches.

And noone seems to be systematically tracking for all patches what 
happens in the end - even cherry-picking an upstream patch might
miss critical later upstream fixes.

The problem here is the huge amount of packages that need changes due to 
the OpenSSL API breakage.

> > People will remember the last time Debian screwed up badly in the area 
> > of OpenSSL, so this could really harm the reputation of Debian.
> > 
> > 4. Schedule
> > The transition freeze was 11 days ago, and the soft freeze is only
> > 1.5 months ahead.
> > If the work on points 1 and 2 above is not mostly finished
> > by December 5th (mandatory 10-day migrations will start, only
> > 1 month until the soft freeze), either the OpenSSL transition
> > or the release schedule have to be scrapped.
> 
> So people still can choose to go for 1.1.0 or 1.0.2. They may work on
> 1.1.0.

Is everyone aware that this choice is per-cluster and not per-package?

One single leaf package that chooses to stay at 1.0.2 and is part
of a cluster implies that you must force all other packages in the 
cluster to also stay at 1.0.2

> 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

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Thu, Nov 17, 2016 at 12:27:43AM -0500, Scott Kitterman wrote:
> On Wednesday, November 16, 2016 10:04:00 PM Lisandro Damián Nicanor Pérez 
> Meyer wrote:
> > On jueves, 17 de noviembre de 2016 00:40:42 ART Kurt Roeckx wrote:
> > > On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote:
> > > > The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
> > > > but that sort of assumes that you are only interested in openssl 1.1 for
> > > > ChaCha20 (and not the other changes).
> > > 
> > > I'm not willing to maintain such a patch.
> > 
> > I am with Kurt here. I myself didn't want to apply an untested patch to qt4
> > to add libssl1.1 support without enough time to test it (because after all
> > qt4 is dead upstream and we can only hope for the best, but not *right*
> > now).
> > 
> > We need to find another option.
> 
> We now have the particularly fun situation where neither openssl 1.1 (due to 
> #844366) nor openssl 1.0 (due to #736687) can get to unstable,
>...

s/unstable/testing/

openssl 1.1 and openssl1.0 have to enter testing at the same time.

#736687 is a non-issue for the transition itself, and the release team 
can force a package into testing ignoring such a bug.

> Scott K

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

Re: OpenSSL 1.1.0

[Scott Kitterman]

On Wednesday, November 16, 2016 10:04:00 PM Lisandro Damián Nicanor Pérez 
Meyer wrote:
> On jueves, 17 de noviembre de 2016 00:40:42 ART Kurt Roeckx wrote:
> > On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote:
> > > The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
> > > but that sort of assumes that you are only interested in openssl 1.1 for
> > > ChaCha20 (and not the other changes).
> > 
> > I'm not willing to maintain such a patch.
> 
> I am with Kurt here. I myself didn't want to apply an untested patch to qt4
> to add libssl1.1 support without enough time to test it (because after all
> qt4 is dead upstream and we can only hope for the best, but not *right*
> now).
> 
> We need to find another option.

We now have the particularly fun situation where neither openssl 1.1 (due to 
#844366) nor openssl 1.0 (due to #736687) can get to unstable, so if your 
package build-depends on openssl it's going to be some time before your 
package gets to unstable no matter which one you pick.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On jueves, 17 de noviembre de 2016 00:40:42 ART Kurt Roeckx wrote:
> On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote:
> > The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
> > but that sort of assumes that you are only interested in openssl 1.1 for
> > ChaCha20 (and not the other changes).
> 
> I'm not willing to maintain such a patch.

I am with Kurt here. I myself didn't want to apply an untested patch to qt4 to 
add libssl1.1 support without enough time to test it (because after all qt4 is 
dead upstream and we can only hope for the best, but not *right* now).

We need to find another option.

-- 
The generation of random numbers is too important to be left to chance.
  http://www.devtopics.com/best-programming-jokes/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 1.1.0

[Kurt Roeckx]

On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote:
> 
> The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
> but that sort of assumes that you are only interested in openssl 1.1 for
> ChaCha20 (and not the other changes).

I'm not willing to maintain such a patch.


Kurt

Re: OpenSSL 1.1.0

[Sebastian Andrzej Siewior]

On 2016-11-16 12:26:55 [+], Ian Jackson wrote:
> If we decide to wind back the transition and the openssl maintainers
> continue not to be available (within the short timeframes required),
> we have a lot of people who could competently prepare an NMU.

NMU openssl back to 1.0.2 or its rdeps to libssl1.0?
Kurt and myself tried to help everyone who asked for help with porting.
Kurt reviewed several patches of people which tried to update 1.1.0.

> Thanks,
> Ian.

Sebastian

Re: OpenSSL 1.1.0

[Sebastian Andrzej Siewior]

On 2016-11-16 19:49:44 [+0200], Adrian Bunk wrote:
> The problem are not specific bugs, the problem is the whole size of the
> problem:
> 
> 1. Sorting out what packages have to stay at 1.0.2
> The majority of OpenSSL-using packages in stretch might end up 
> using 1.0.2 - sorting this out is part of the ongoing OpenSSL
> transition.

You have two choices: either port it to 1.1.0 and stay with 1.0.2.

> 2. OpenSSL 1.1 support is often only build-tested
> We are currently at 650 packages in unstable depending on libssl1.0.2, 
> and when binNMUs will happen we might get a three-digit number of
> new RC bugs like #843988 and #843532.

stunnel was prepared upstream to work with 1.1.0 and it wasn't perfect.
We would also face the same problem if openssl 1.0.2 decided to do a
realloc() at some point. Lucky it did not yet. Some package run a
testsuite so we find bugs there, too.

> 3. Another Debian OpenSSL security fiasco?
> Bugs like #843988 are only about problems that show up immediately.
> This is often code where mistakes can be CVEs, and bug #843988 or
> the comment "With Kurt's patch, apache2 crashes on startup" don't
> make me optimistic regarding silent new security holes.
> Depending on how/if this was applied upstream, these might become
> Debian-specific CVEs.

I forwaded (or tried) my 1.1.0 fixups to upstream. I didn't find alive
upstream for the two perl patches I made and had hope that the debian
maintainer knows how to forwarded them.

> People will remember the last time Debian screwed up badly in the area 
> of OpenSSL, so this could really harm the reputation of Debian.
> 
> 4. Schedule
> The transition freeze was 11 days ago, and the soft freeze is only
> 1.5 months ahead.
> If the work on points 1 and 2 above is not mostly finished
> by December 5th (mandatory 10-day migrations will start, only
> 1 month until the soft freeze), either the OpenSSL transition
> or the release schedule have to be scrapped.

So people still can choose to go for 1.1.0 or 1.0.2. They may work on
1.1.0.

> cu
> Adrian

Sebastian

Re: OpenSSL 1.1.0

[Niels Thykier]

Ian Jackson:
> Ian Jackson writes ("Re: OpenSSL 1.1.0"):
> [...]
> 
> I was not able to find the message where the release team gave
> permission for the upload of openssl 1.1.x (in particular, the new
> version of libssl-dev) to unstable, that started the transition. [...]
> 
> [...]
> 
> Ian.
> 

Kurt received acknowledgement from the release team before uploading
ssl1.1 as the default.

~Niels





signature.asc
Description: OpenPGP digital signature

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Wed, Nov 16, 2016 at 12:15:39AM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-15 00:16:14 [+0200], Adrian Bunk wrote:
> > And since 80% of all OpenSSL-using packages in unstable are still
> > using libssl1.0.2 (binNMUs have not yet happened), all runtime
> > issues observed so far are only the tip of the iceberg.
> > Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid 
> > free." 
> > or #843988 will be a common sight on the list of RC bugs for several
> > months in any scenario with OpenSSL 1.1 as default.
> Are you afraid of bugs or that nobody will look after them? Can't speak
> for apache but #843988 got patched and so did #843532.

The problem are not specific bugs, the problem is the whole size of the
problem:

1. Sorting out what packages have to stay at 1.0.2
The majority of OpenSSL-using packages in stretch might end up 
using 1.0.2 - sorting this out is part of the ongoing OpenSSL
transition.

2. OpenSSL 1.1 support is often only build-tested
We are currently at 650 packages in unstable depending on libssl1.0.2, 
and when binNMUs will happen we might get a three-digit number of
new RC bugs like #843988 and #843532.

3. Another Debian OpenSSL security fiasco?
Bugs like #843988 are only about problems that show up immediately.
This is often code where mistakes can be CVEs, and bug #843988 or
the comment "With Kurt's patch, apache2 crashes on startup" don't
make me optimistic regarding silent new security holes.
Depending on how/if this was applied upstream, these might become
Debian-specific CVEs.
People will remember the last time Debian screwed up badly in the area 
of OpenSSL, so this could really harm the reputation of Debian.

4. Schedule
The transition freeze was 11 days ago, and the soft freeze is only
1.5 months ahead.
If the work on points 1 and 2 above is not mostly finished
by December 5th (mandatory 10-day migrations will start, only
1 month until the soft freeze), either the OpenSSL transition
or the release schedule have to be scrapped.

> 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

Re: OpenSSL 1.1.0

[Ian Jackson]

Jonathan Wiltshire writes ("Re: OpenSSL 1.1.0"):
> On 2016-11-16 12:26, Ian Jackson wrote:
> > If we are going to wind back on this change we should do it ASAP.  We
> > should not allow ourselves to make the decision to press on, simply by
> > failing to decide otherwise.
> 
> Indeed it's been under discussion for the past week or so independent of 
> the thread on -devel. I hope you'll forgive me for not breaking 
> confidences just yet, but we expect to be able to resolve this very 
> soon.

Excellent, I'm glad to hear that you're discussing it.

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.

Re: OpenSSL 1.1.0

[Carsten Leonhardt]

Ian Jackson  writes:

> Reading that bug I think it's a shame that we didn't manage to
> effectively identify the issues we've now discussed here on -devel
> earlier, despite Kurt's several messages to d-d-a.

Concerns were already raised in June, in the subthread starting here:
https://lists.debian.org/debian-devel/2016/06/msg00501.html but they
were not responded to.

- Carsten

Re: OpenSSL 1.1.0

[Adam Borowski]

On Mon, Nov 14, 2016 at 03:37:00PM +0100, Adam Borowski wrote:
> Another issue: 1.0.2 is a LTS, supported until 2019-12-31, while 1.1.0 a
> short-lived release with upstream support only until 2018-08-31.

Hmm... a different interpretation of these two data points:

Stretch's EOL is projected for May 2022 (LTS), and even regular support will
exceed the EOL of either of the above openssl branches.  It'll be a lot
easier to backport fixes from 1.1.1+ to 1.1.0 than 1.0.2, and security
issues that don't apply to the 1.1 branch won't be even reported.

This gains us anything only for the "1.1.0 only" variant, though, which
doesn't sound possible.

-- 
A true bird-watcher waves his tail while doing so.

Re: OpenSSL 1.1.0

[Jonathan Wiltshire]

On 2016-11-16 12:26, Ian Jackson wrote:

In the absence of input from the openssl maintainers, I would like to
ask the Release Team's opinion.

If we are going to wind back on this change we should do it ASAP.  We
should not allow ourselves to make the decision to press on, simply by
failing to decide otherwise.


Indeed it's been under discussion for the past week or so independent of 
the thread on -devel. I hope you'll forgive me for not breaking 
confidences just yet, but we expect to be able to resolve this very 
soon.



--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits

Re: OpenSSL 1.1.0

[Ian Jackson]

Ian Jackson writes ("Re: OpenSSL 1.1.0"):
> Ian Jackson writes ("Re: OpenSSL 1.1.0"):
> > Lots of people have posted in this thread that they see problems with
> > our current approach to the openssl transition.
> > 
> > Do the openssl maintainers have an response ?
...
> In the absence of input from the openssl maintainers, I would like to
> ask the Release Team's opinion.

I tried to find previous opinions of the release team by reading the
transition bug #827061.

I was not able to find the message where the release team gave
permission for the upload of openssl 1.1.x (in particular, the new
version of libssl-dev) to unstable, that started the transition.  Can
someone point me to the formal instruction to upload to unstable ?  Or
was permission granted by irc or something ?

The most recent message I can find from a release team member in that
bug report is:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061#944
That does seem to suggest that in late October the release team had
more or less decided to go ahead.

Reading that bug I think it's a shame that we didn't manage to
effectively identify the issues we've now discussed here on -devel
earlier, despite Kurt's several messages to d-d-a.

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.

Re: OpenSSL 1.1.0

[Moritz Mühlenhoff]

Stephan Seitz wrote:
> And there is still the problem that 1.1.0 is not supported as long as the
> available LTS version.

That's not a decisive factor, Debian security support has been extended
over the upstream support time frame many times before.

Cheers,
Moritz

Re: OpenSSL 1.1.0

[Stephan Seitz]

On Mi, Nov 16, 2016 at 02:31:28 +0100, Marco d'Itri wrote:

ChaCha20 is hardly obscure: if it is to you then I fear that your
opinion on this issue is not informed enough to be useful.


It doesn’t matter in the end.

If no one wants to delay the next release until all applications support 
OpenSSL 1.1.0 in a secure way even is upstream may not be interested in 
patching the software for now then we can’t have version 1.1.0.


And there is still the problem that 1.1.0 is not supported as long as the 
available LTS version.


Many greetings,

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: OpenSSL 1.1.0

[Marco d'Itri]

On Nov 16, Pau Garcia i Quiles  wrote:

> * Some obscure feature (e. g. BlaBla20) may be missing or be difficult
> to support on a limited number of packages (e. g. apache2)
ChaCha20 is hardly obscure: if it is to you then I fear that your 
opinion on this issue is not informed enough to be useful.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: OpenSSL 1.1.0

[Pau Garcia i Quiles]

On Wed, Nov 16, 2016 at 1:58 PM, Pau Garcia i Quiles
 wrote:

[...]
> OpenSSL 1.0 only
> =
[...]
> * Some obscure feature (e. g. BlaBla20) may be missing or be difficult
> to support on a limited number of packages (e. g. apache2)
[...]

Sorry, it's ChaCha20, not BlaBla20. My bad.


-- 
Pau Garcia i Quiles
http://www.elpauer.org

Re: OpenSSL 1.1.0

[Pau Garcia i Quiles]

On Wed, Nov 16, 2016 at 1:26 PM, Ian Jackson
 wrote:

> A maintainer should be ready to explain, and if necessary change,
> decisions they have taken.  (Ideally wider consultation before taking
> such a decision would be better.)
>
> In the absence of input from the openssl maintainers, I would like to
> ask the Release Team's opinion.
>
> If we are going to wind back on this change we should do it ASAP.  We
> should not allow ourselves to make the decision to press on, simply by
> failing to decide otherwise.
>
> If we decide to wind back the transition and the openssl maintainers
> continue not to be available (within the short timeframes required),
> we have a lot of people who could competently prepare an NMU.

>From a project management point of view, I can see three alternatives

OpenSSL 1.0 only
=

* All packages work fine
* No release delays
* We will be using an LTS version of OpenSSL
* Some obscure feature (e. g. BlaBla20) may be missing or be difficult
to support on a limited number of packages (e. g. apache2)


OpenSSL 1.1 only
=

* Many packages do not support OpenSSL in upstream, therefore they
need patching from Debian maintainer (security risk). Some packages do
not have a maintainer volunteer that can provide this patch.
* Release delay between 6-12 months seems certain
* We will be using version of OpenSSL with support end date before
Stretch's support end date
* We will be providing all new features that come with OpenSSL


OpenSSL 1.0 + 1.1
==

* Every package will be buildable but we can expect surprises on
runtime due to dlopen'ed libraries, indirect use, etc
* Release delay seems certain but difficult to determine
* Even with a release delay, we cannot be 100% sure all the rutnime
surprises will be gone
* We need to support 2 versions of OpenSSL and be prepared for
third-party applications (not included with Debian) to fail due to
runtime surprises
* Different support cycles upstream (one LTSL, one not)
* We will be providing both versions of OpenSSL for the end-user to
choose (when he has the knowledge)


If I were in charge of taking this decision:

* OpenSSL 1.0 + 1.1 would be out. It's the worst possible scenario:
even with a delay, I can expect problems
* OpenSSL 1.1 will delay the release and/or leave a lot of packages out
* OpenSSL 1.0 makes possible to release as planned and provides an LTS
release. The minor inconveniences for missing ciphers, etc do not
justify the negative impact of the other choices, IMO.

So I would release Stretch with OpenSSL 1.0 only, and then make a plan:
1. OpenSSL 1.1 is gone from sid effective immediately and move to experimental
2. On April 1st 2017 we replace OpenSSL 1.0 with OpenSSL 1.1 in sid.
All packages are expected to support OpenSSL 1.1 only by this date.
3. Stabilize and aim for a quick Debian release 1 year after Stretch.
Yes, that means 2 Debian versions supported for some time.

Of course, that's just my suggestion. Feel free to disagree.

-- 
Pau Garcia i Quiles
http://www.elpauer.org

Re: OpenSSL 1.1.0

[Ian Jackson]

Ian Jackson writes ("Re: OpenSSL 1.1.0"):
> Lots of people have posted in this thread that they see problems with
> our current approach to the openssl transition.
> 
> Do the openssl maintainers have an response ?

I count the following people who expressed concern[1] about this some
time before the 11th of November (last activity from an openssl
maintainer):

   Lisandro Damin Nicanor Prez Meyer
   Ian Jackson
   Pau Garcia i Quiles
   Colin Tuckley
   Jan Niehusmann

On the 11th Kurt replied, but only to a specific technical aspect of
Jan Niehusmann's message.  (On the 10th there was a second openssl
revision upload.)  It seems to me that there has been no real answer
to most of those comments, and ample time to do so.

Since then I additionally count the following people who have
expressed concern[1]:

   Jan Wagner
   Ondřej Surý
   Adam Borowski
   Russ Allbery
   Dimitri John Ledkov
   Jan Niehusmann
   Adrian Bunk
   Scott Leggett

I appreciate that not everyone can be available all of the time, but
a maintainer has a choice of when to initiate a transition and should
arrange to do so at a time when they can be available in a timely
manner to help steward their transition.

A maintainer should be ready to explain, and if necessary change,
decisions they have taken.  (Ideally wider consultation before taking
such a decision would be better.)

In the absence of input from the openssl maintainers, I would like to
ask the Release Team's opinion.

If we are going to wind back on this change we should do it ASAP.  We
should not allow ourselves to make the decision to press on, simply by
failing to decide otherwise.

If we decide to wind back the transition and the openssl maintainers
continue not to be available (within the short timeframes required),
we have a lot of people who could competently prepare an NMU.

Thanks,
Ian.

[1] I have had to make some judgements about the implications in
people's mails.  "Expresse concern" for me includes suggestions that
the current situation would need a substantial slip to the release.

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

Re: OpenSSL 1.1.0 / transition process

[Daniel Pocock]

On 16/11/16 00:01, Sebastian Andrzej Siewior wrote:
> On 2016-11-15 17:42:59 [+0100], Daniel Pocock wrote:
>> Would the OpenSSL maintainers and/or release managers consider making a
>> wiki page about the transition with the most common questions about it,
>> similar to the upstream wiki but with a Debian focus?
> 
> I started one at
>   https://wiki.debian.org/OpenSSL-1.1
> 

Great, thanks for doing that, I dropped in a couple of additional
questions (testing upstream builds with travis-ci, testing on jessie)

Re: OpenSSL 1.1.0 / transition process

[Jonas Smedegaard]

Quoting Sebastian Andrzej Siewior (2016-11-16 00:01:06)
> On 2016-11-15 17:42:59 [+0100], Daniel Pocock wrote:
> > Would the OpenSSL maintainers and/or release managers consider 
> > making a wiki page about the transition with the most common 
> > questions about it, similar to the upstream wiki but with a Debian 
> > focus?
> 
> I started one at
> https://wiki.debian.org/OpenSSL-1.1

Great!


> > The questions which come to my mind (and may already be answered):
> > 
> > - will it definitely go ahead for stretch?
> > 
> > - will the stretch freeze and release dates be delayed to allow 
> > people to catch up?
> > 
> > - is it expected that package maintainers spend time patching for 
> > this, or we can wait for upstreams to support it?
[...]
> - BTS user tags bugs. All bugs reported by Kurt and myself were user
>   tagged.

 - will those user-tagged bugs properly track all related issues too?

As an example, Bug#828590 for uwsgi is currently being addressed.  When 
I can hopefully upload that package tomorrow, the package evidently no 
longer fails to build from source and the FTBFS bug can therefore be 
closed.  But at the same time other bugs - less severe, but directly 
caused by the conflicting libssl libraries - will emerge¹.  I can try to 
treat such collateral issues as related - e.g. by cloning and adapting, 
and/or by keeping open the original bug and renaming it, and maybe by 
user-tagging (if someone documents what tagging is suitable - I sure 
don't want to make things worse by sloppy bug tagging).  But it seems to 
me that there is a real risk that some of the bugs tracked in above wiki 
page may miss out on some similar collateral problems in other packages.

 - Jonas

¹ uwsgi build-depends not only on libssl-dev, but also libapache-dev, 
php-dev and libcurl4-openssl-dev now linking against conflicting 
libssl*-dev packages.

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: OpenSSL 1.1.0

[Sebastian Andrzej Siewior]

On 2016-11-15 00:16:14 [+0200], Adrian Bunk wrote:
> And since 80% of all OpenSSL-using packages in unstable are still
> using libssl1.0.2 (binNMUs have not yet happened), all runtime
> issues observed so far are only the tip of the iceberg.
> Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid 
> free." 
> or #843988 will be a common sight on the list of RC bugs for several
> months in any scenario with OpenSSL 1.1 as default.
Are you afraid of bugs or that nobody will look after them? Can't speak
for apache but #843988 got patched and so did #843532.

Sebastian

Re: OpenSSL 1.1.0 / transition process

[Sebastian Andrzej Siewior]

On 2016-11-15 17:42:59 [+0100], Daniel Pocock wrote:
> Would the OpenSSL maintainers and/or release managers consider making a
> wiki page about the transition with the most common questions about it,
> similar to the upstream wiki but with a Debian focus?

I started one at
https://wiki.debian.org/OpenSSL-1.1

> The questions which come to my mind (and may already be answered):
> 
> - will it definitely go ahead for stretch?
> 
> - will the stretch freeze and release dates be delayed to allow people
> to catch up?
> 
> - is it expected that package maintainers spend time patching for this,
> or we can wait for upstreams to support it?

I can't answer those. I just copied them into the Wiki hoping someone
will.

> - given the huge number of packages listed on the transition page, I
> couldn't help feeling that it would be useful to be able to get some
> reports about how many packages have now had a bug forwarded upstream,
> how many upstreams have released a newer version with the fix, how many
> upstreams have a fix that is not released, etc

I added to the wiki a few links:
- my ben page. Similar to release team's page but it shows which package
  moved to 1.0 and which more towards 1.1. (updated ~17.15 UTC).

- BTS user tags bugs. All bugs reported by Kurt and myself were user
  tagged.

> Regards,
> 
> Daniel

Sebastian

Re: OpenSSL 1.1.0 / transition process

[Daniel Pocock]

On 15/11/16 16:54, Ian Jackson wrote:
> Lots of people have posted in this thread that they see problems with
> our current approach to the openssl transition.
>
> Do the openssl maintainers have an response ?

I just started looking at this thread 2 minutes ago.  I really don't
know where to start.

Would the OpenSSL maintainers and/or release managers consider making a
wiki page about the transition with the most common questions about it,
similar to the upstream wiki but with a Debian focus?

The questions which come to my mind (and may already be answered):

- will it definitely go ahead for stretch?

- will the stretch freeze and release dates be delayed to allow people
to catch up?

- is it expected that package maintainers spend time patching for this,
or we can wait for upstreams to support it?

- given the huge number of packages listed on the transition page, I
couldn't help feeling that it would be useful to be able to get some
reports about how many packages have now had a bug forwarded upstream,
how many upstreams have released a newer version with the fix, how many
upstreams have a fix that is not released, etc

Wearing my upstream hat, I do hope to ensure my own packages support it
sooner rather than later.  Some of them will go into NEW though because
they have ABI or API version numbers in the binary package names, so
they won't be available immediately.

Regards,

Daniel

Re: OpenSSL 1.1.0

[Ian Jackson]

Lots of people have posted in this thread that they see problems with
our current approach to the openssl transition.

Do the openssl maintainers have an response ?

Thanks,
Ian.

-- 
Ian Jackson    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.

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Tue, Nov 15, 2016 at 07:03:28PM +1100, Scott Leggett wrote:
> On 2016-11-15.00:16, Adrian Bunk wrote:
> > Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid 
> > free." 
> > or #843988 will be a common sight on the list of RC bugs for several
> > months in any scenario with OpenSSL 1.1 as default.
> >
> > ...
> >
> > 2. move the stretch release schedule by 6-12 months to have
> >only OpenSSL 1.1 in stretch
> 
> So with OpenSSL 1.1 in stretch, the release schedule is going to move by
> 6-12 months regardless?

Shipping OpenSSL 1.1 as security-supported technology preview in stretch,
and a few packages that both work with OpenSSL 1.1 and do not have 
inter(r)dependencies with packages that don't work properly with OpenSSL 
1.1 could use it - that would be possible without negative impact on the 
release schedule.

> Regards,
> Scott.

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

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Tue, Nov 15, 2016 at 09:37:01AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote:
> > On Nov 14, Lisandro Damián Nicanor Pérez Meyer  wrote:
> > > And yes, I would step back and switch libssl-dev to provide libssl1.0-dev
> > > and have libssl1.1-dev around for anyone who can really do the switch.
> > I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
> > bad default for next year's release.
> > Bad enough that I would have to use a different distribution for some
> > web servers.
> 
> That's why I wrote:
> 
>   And if we **really** need to switch to libssl1.1 then we **really** need to
>   delay the release by 6 months as a very minimum, maybe 1 year.
> 
> Yes, I also know that it sounds awful, but do we have another way out?

Yes, patching the OpenSSL 1.1 features that are really needed into the
Debian OpenSSL 1.0.2 package.

For ChaCha20 that's existing patches that are already being used
elsewhere.

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

Re: OpenSSL 1.1.0

[Jan Niehusmann]

On Tue, Nov 15, 2016 at 10:43:07AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On lunes, 14 de noviembre de 2016 22:16:25 ART Jan Niehusmann wrote:
> [snip] 
> > (It's fine if packages which depend on libssl-dev get an RC-bug if they
> > can't be compiled with OpenSSL 1.1. Packages which can't be ported
> > should explicitly depend on libssl1.0-dev. That way we'll make progress
> > towards a point where we can start a smooth transition.)
> 
> I *really* disagree with that. Swtiching libssl-dev to provide libssl1.1-dev 
> means that some apps/libs will get automatically recompiled and some of them 
> might even not FTBFS (because for example, they are ready to use 1.1).
> 
> That means we left the door open to crashes due to mixed libssl versions.

I probably didn't state that clear enough: I don't think libssl-dev
should provide libssl1.1-dev.

But building packages - purely for testing purposes - against
libssl1.1-dev and reporting any issues is a good thing, and I even think
such bugs could be marked RC, to make sure we make progress.

At the same time, I don't want to remove packages which can't be ported
quickly. Therefore, either these bugs can't be RC, or there must be an
easy way for maintainers to opt out. One way of such an opt-out would be
changing the dependency to libssl1.0-dev.

However, the quoted paragraph was meant as a side-note only. It's not
important, at the moment.


The one thing we should decide *quickly* is if we want to revert
libssl-dev back to 1.0, or if we want to delay the freeze by several
months.

> By letting libssl-dev provide libssl1.0 we do not open this door, and we let 
> maintainers decide on a per-basis case.

Yes, and we avoid cases like with libcurl3, where the recompile to
libssl1.1 broke ABI compatibility of libcurl3 without notice.

Jan

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On martes, 15 de noviembre de 2016 14:52:15 ART Bernd Zeimetz wrote:
> On 2016-11-15 14:43, Lisandro Damián Nicanor Pérez Meyer wrote:
> > I *really* disagree with that. Swtiching libssl-dev to provide
> > libssl1.1-dev
> > means that some apps/libs will get automatically recompiled and some of
> > them
> > might even not FTBFS (because for example, they are ready to use 1.1).
> 
> If a 1.1.0 ready package ftbfs when libssl-dev points to 1.0 it is a bug
> that
> should be fixed anyway. There is no real reason not to support both
> versions.

A bug which, IMO, should not be RC right now, but switching libssl-dev to 
provide libssl1.1 *now* will probably hide crashes in the case I described 
above.

So yes, I agree with you, I just don't agree this is the right time. Doing it 
as soon as the buster release cycle starts it's just fine.

> > That means we left the door open to crashes due to mixed libssl
> > versions.
> > 
> > By letting libssl-dev provide libssl1.0 we do not open this door, and
> > we let
> > maintainers decide on a per-basis case.
> 
> And we have to maintain two openssl versions trough the release cycle.

For stretch we will already have, except we delay the release by ~1 year. 
Which again, if it's deemed necessary, then we should consider it.

-- 
Una vez que hemos eliminado lo imposible, lo que queda, por improbable que
parezca, es la verdad.
  Sherlock Holmes

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 1.1.0

[Bernd Zeimetz]

On 2016-11-15 14:43, Lisandro Damián Nicanor Pérez Meyer wrote:

I *really* disagree with that. Swtiching libssl-dev to provide 
libssl1.1-dev
means that some apps/libs will get automatically recompiled and some of 
them

might even not FTBFS (because for example, they are ready to use 1.1).


If a 1.1.0 ready package ftbfs when libssl-dev points to 1.0 it is a bug 
that
should be fixed anyway. There is no real reason not to support both 
versions.



That means we left the door open to crashes due to mixed libssl 
versions.


By letting libssl-dev provide libssl1.0 we do not open this door, and 
we let

maintainers decide on a per-basis case.


And we have to maintain two openssl versions trough the release cycle.



--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 14 de noviembre de 2016 22:16:25 ART Jan Niehusmann wrote:
[snip] 
> (It's fine if packages which depend on libssl-dev get an RC-bug if they
> can't be compiled with OpenSSL 1.1. Packages which can't be ported
> should explicitly depend on libssl1.0-dev. That way we'll make progress
> towards a point where we can start a smooth transition.)

I *really* disagree with that. Swtiching libssl-dev to provide libssl1.1-dev 
means that some apps/libs will get automatically recompiled and some of them 
might even not FTBFS (because for example, they are ready to use 1.1).

That means we left the door open to crashes due to mixed libssl versions.

By letting libssl-dev provide libssl1.0 we do not open this door, and we let 
maintainers decide on a per-basis case.

-- 
You are the Doc, Doc!
  Marty McFly To Dr. Emmett Brown, Back to the Future III

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote:
> On Nov 14, Lisandro Damián Nicanor Pérez Meyer  wrote:
> > And yes, I would step back and switch libssl-dev to provide libssl1.0-dev
> > and have libssl1.1-dev around for anyone who can really do the switch.
> I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
> bad default for next year's release.
> Bad enough that I would have to use a different distribution for some
> web servers.

That's why I wrote:

  And if we **really** need to switch to libssl1.1 then we **really** need to
  delay the release by 6 months as a very minimum, maybe 1 year.

Yes, I also know that it sounds awful, but do we have another way out?

-- 
Ponga su mano en una estufa caliente por un minuto, y le parecerá como una
hora. Siéntese con una muchacha bonita por una hora, y le parecerá un minuto.
¡Eso es relatividad!.
 Albert Einstein (1879-1955)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/



signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 1.1.0

[Bernd Zeimetz]

On 2016-11-15 11:59, Jonas Smedegaard wrote:


4. use libapache2-mod-gnutls?


that might work for you, but its nothing the common debian user will
do.

--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: OpenSSL 1.1.0

[Jonas Smedegaard]

Quoting Adrian Bunk (2016-11-14 23:16:14)
> On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote:
>> Marco d'Itri:
>>> On Nov 14, Lisandro Damián Nicanor Pérez Meyer  wrote:
 And yes, I would step back and switch libssl-dev to provide 
 libssl1.0-dev and have libssl1.1-dev around for anyone who can 
 really do the switch.
>>> I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a 
>>> very bad default for next year's release.
>>> Bad enough that I would have to use a different distribution for 
>>> some web servers.
[...]
> For Apache, the choices available are:
> 1. no ChaCha20 in Apache in stretch
> 2. move the stretch release schedule by 6-12 months to have
>only OpenSSL 1.1 in stretch
> 3. apply ChaCha20 patches to OpenSSL 1.0.2

4. use libapache2-mod-gnutls?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: OpenSSL 1.1.0

[Scott Leggett]

On 2016-11-15.00:16, Adrian Bunk wrote:
> Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid 
> free." 
> or #843988 will be a common sight on the list of RC bugs for several
> months in any scenario with OpenSSL 1.1 as default.
>
> ...
>
> 2. move the stretch release schedule by 6-12 months to have
>only OpenSSL 1.1 in stretch

So with OpenSSL 1.1 in stretch, the release schedule is going to move by
6-12 months regardless?

-- 
Regards,
Scott.


signature.asc
Description: Digital signature

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote:
> Marco d'Itri:
> > On Nov 14, Lisandro Damián Nicanor Pérez Meyer  wrote:
> > 
> >> And yes, I would step back and switch libssl-dev to provide libssl1.0-dev 
> >> and 
> >> have libssl1.1-dev around for anyone who can really do the switch.
> > I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very 
> > bad default for next year's release.
> > Bad enough that I would have to use a different distribution for some 
> > web servers.
> 
> At the moment, the maintainers of apache2 are picking the openssl 1.0
> route.
>...

For libcurl3 the OpenSSL version is part of the ABI due to SSL_CTX.
If packages linked with libcurl3 use a different OpenSSL version than
libcurl3, that can break badly.

Apache seems to have similar problems.

Such packages do not even have a choice of going to 1.1 since that would
make it impossible for their rdeps to use 1.0.2

> The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
> but that sort of assumes that you are only interested in openssl 1.1 for
> ChaCha20 (and not the other changes).

Trying to mix OpenSSL 1.0.2 and 1.1 is the expected mess.

And since 80% of all OpenSSL-using packages in unstable are still
using libssl1.0.2 (binNMUs have not yet happened), all runtime
issues observed so far are only the tip of the iceberg.
Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid free." 
or #843988 will be a common sight on the list of RC bugs for several
months in any scenario with OpenSSL 1.1 as default.

For Apache, the choices available are:
1. no ChaCha20 in Apache in stretch
2. move the stretch release schedule by 6-12 months to have
   only OpenSSL 1.1 in stretch
3. apply ChaCha20 patches to OpenSSL 1.0.2

You have the same choices for any other OpenSSL 1.1 features you
consider important.

Any explicit or implicit claims that you could just switch a package
like Apache to OpenSSL 1.1 within the current stretch release schedule
are just resulting in a lot of people wasting a lot of time.

> Thanks,
> ~Niels
>...

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

Re: OpenSSL 1.1.0

[Jan Niehusmann]

On Mon, Nov 14, 2016 at 10:45:50AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and 
> have libssl1.1-dev around for anyone who can really do the switch.

That's the only viable alternative I see.

It looks like an increasing number of packages, including apache2,
openssh, qt4 and qt5, picked to build-depend on libssl1.0-dev.

So OpenSSL 1.0 won't go away, and through packages indirectly depending
on both versions, we'll get very difficult to solve conflicts.

As removing all those packages clearly is not an option, the release
will be significantly delayed if we don't revert the default to be
OpenSSL 1.0.

(It's fine if packages which depend on libssl-dev get an RC-bug if they
can't be compiled with OpenSSL 1.1. Packages which can't be ported
should explicitly depend on libssl1.0-dev. That way we'll make progress
towards a point where we can start a smooth transition.)

I'd be glad to have a quick transition to OpenSSL 1.1 now, but I honestly
don't see a way how this may work.

Please revert the default back to 1.0 for now.

Jan

Re: OpenSSL 1.1.0

[Niels Thykier]

Niels Thykier:
> Marco d'Itri:
>> On Nov 14, Lisandro Damián Nicanor Pérez Meyer  wrote:
>>
>>> And yes, I would step back and switch libssl-dev to provide libssl1.0-dev 
>>> and 
>>> have libssl1.1-dev around for anyone who can really do the switch.
>> I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very 
>> bad default for next year's release.
>> Bad enough that I would have to use a different distribution for some 
>> web servers.
>>
> 
> At the moment, the maintainers of apache2 are picking the openssl 1.0
> route.  So at this rate, you would not get ChaCha20 for apache2 in
> stretch anyway even if ssl1.1 says the "default"... :-/
> 
> [...]
> 
> Thanks,
> ~Niels
> 

For avoidance of doubt, this was not aimed at the apache2 maintainers.
I appreciate that "ssl1.0 vs. ssl1.1" is not an entirely easy decision
for maintainers - especially as it affects reverse dependencies as well.

The apache2 case was mentioned because I deemed it relevant to Marco's
argument.

~Niels

Re: OpenSSL 1.1.0

[Niels Thykier]

Marco d'Itri:
> On Nov 14, Lisandro Damián Nicanor Pérez Meyer  wrote:
> 
>> And yes, I would step back and switch libssl-dev to provide libssl1.0-dev 
>> and 
>> have libssl1.1-dev around for anyone who can really do the switch.
> I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very 
> bad default for next year's release.
> Bad enough that I would have to use a different distribution for some 
> web servers.
> 

At the moment, the maintainers of apache2 are picking the openssl 1.0
route.  So at this rate, you would not get ChaCha20 for apache2 in
stretch anyway even if ssl1.1 says the "default"... :-/

The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
but that sort of assumes that you are only interested in openssl 1.1 for
ChaCha20 (and not the other changes).

Thanks,
~Niels

[1] https://github.com/cloudflare/sslconfig/tree/master/patches

Re: OpenSSL 1.1.0

[Dimitri John Ledkov]

There is a large number of packages currently build-depending on
openssl 1.0 explicitly.
Supporting dual-stack 1.0 & 1.1 openssl is a lot of work.
In Ubuntu, I have reverted the 1.1 migration, and forced 1.0 to be
used and provided by both libssl-dev & libssl1.0-dev packages.
This was done after a consensus consultation with some of the ubuntu
developers, archive admins, and security team.
If the transition in Debian goes really well, I see Ubuntu picking it
up for 17.10. Realistically, I see it for the 18.04 LTS cycle.

-- 
Regards,

Dimitri.

Re: OpenSSL 1.1.0

[Russ Allbery]

Ondřej Surý  writes:

> And this is happening all over places (apache2 vs php7.0) - I don't
> think we can have a partial transition. It's now all or nothing.

xml-security-c has not yet been ported to OpenSSL 1.1 upstream (which is
non-trivial), and we're now at an impasse in the Shibboleth suite because
cURL is using 1.1, but xml-security-c and Apache both need 1.0.

I agree with Ondřej: the current transition state is not releasable.  We
need to figure out something else.

-- 
Russ Allbery (r...@debian.org)   

Re: OpenSSL 1.1.0

[Marco d'Itri]

On Nov 14, Lisandro Damián Nicanor Pérez Meyer  wrote:

> And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and 
> have libssl1.1-dev around for anyone who can really do the switch.
I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very 
bad default for next year's release.
Bad enough that I would have to use a different distribution for some 
web servers.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: OpenSSL 1.1.0

[Adam Borowski]

On Mon, Nov 14, 2016 at 10:45:50AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On lunes, 14 de noviembre de 2016 13:26:44 ART Ondřej Surý wrote:
> > And this is happening all over places (apache2 vs php7.0) - I don't
> > think we can have a partial transition. It's now all or nothing.
> 
> I've said it before, I say it again: this transition should *not* have 
> happened at this point of the release cycle.

Another issue: 1.0.2 is a LTS, supported until 2019-12-31, while 1.1.0 a
short-lived release with upstream support only until 2018-08-31.

-- 
A true bird-watcher waves his tail while doing so.

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 14 de noviembre de 2016 13:26:44 ART Ondřej Surý wrote:
> And this is happening all over places (apache2 vs php7.0) - I don't
> think we can have a partial transition. It's now all or nothing.

I've said it before, I say it again: this transition should *not* have 
happened at this point of the release cycle.

Don't get me wrong: I do perfectly understand why people would like to have 
the new libssl around, but switching libssl-dev *now* was definitely not a 
good idea. Doing it as soon as we start with buster is another story.

And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and 
have libssl1.1-dev around for anyone who can really do the switch.

And if we *really* need to switch to libssl1.1 then we *really* need to delay 
the release by 6 months as a very minimum, maybe 1 year.

-- 
mathematician, n.:
Some one who believes imaginary things appear right before your i's.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 1.1.0

[Ondřej Surý]

And this is happening all over places (apache2 vs php7.0) - I don't
think we can have a partial transition. It's now all or nothing.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Sun, Nov 13, 2016, at 22:03, Bernd Zeimetz wrote:
> Hi,
> 
> so whats your suggestions to solve issues like I have with
> open-vm-tools: Most build-dependencies switch to 1.1.0 - but one
> (libxml-security-c-dev) sticks with 1.0, as far as I've seen in the bts
> because shibboleth won't be able to use 1.1.0.
> 
> Not shipping open-vm-tools is not an option, as it will break support
> for Debian on basically all installations under a vmware hypervisor.
> Which are a lot.
> 
> Whats your suggestion?
> 
> 
> Best regards,
> 
> Bernd
> 
> P.S. imho the time for the openssl transition was the worst one possible
> at all, it *will* result in security bugs and/or a delayed release.
> 
> 
> -- 
>  Bernd ZeimetzDebian GNU/Linux Developer
>  http://bzed.dehttp://www.debian.org
>  GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
> 
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

Re: OpenSSL 1.1.0

[Bernd Zeimetz]

Hi,

so whats your suggestions to solve issues like I have with
open-vm-tools: Most build-dependencies switch to 1.1.0 - but one
(libxml-security-c-dev) sticks with 1.0, as far as I've seen in the bts
because shibboleth won't be able to use 1.1.0.

Not shipping open-vm-tools is not an option, as it will break support
for Debian on basically all installations under a vmware hypervisor.
Which are a lot.

Whats your suggestion?


Best regards,

Bernd

P.S. imho the time for the openssl transition was the worst one possible
at all, it *will* result in security bugs and/or a delayed release.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

Re: OpenSSL 1.1.0

[Jan Wagner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi there,

Am 02.11.2016 um 21:15 schrieb Kurt Roeckx:
> I don't think having libssl1-1-dev vs libssl1.0-dev is going to 
> make much differences in the end. The build conflicts will always 
> have to be sorted out.

thats the point where I rushed into another problem,
monitoring-plugins isn't compatible with openssl 1.1[1]. So you might
argue just to link against libssl1.0-dev.
The issue is that monitoring-plugins makes massive use of other
libraries. When now installing libssl1.0-dev all packages build
against libssl1-1-dev will be removed. The first lib I spotted was
libpq-dev, I expect more to follow.

This means now I can hope to get openssl 1.1 support (under pressure)
for monititoring-plugins and every lib works hopefully well with it.
When no openssl 1.1 support will be available, I can try to depend on
libssl1.0-dev, but can not build all plugins that was shiped with jessie
.

This doesn't look like a smooth move for monitoring-plugins.

Just my 2 cents, Jan.
[1] https://bugs.debian.org/844031
- -- 
Never write mail to , you have been warned!
- -BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V-
PS PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
- --END GEEK CODE BLOCK--
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYJkZbAAoJEAxwVXtaBlE+bAEP/RNEI7EXv5BNIo/y3Yo9acI/
4kK6XwLbAUUcQSuyVtFgz4kiqiQsfk/X8gwwvLFEFZ0UNZCOCslv/2/2bJs6vnRX
lQ60l3g/OGdZ72O0qVnrLDfVm28oIqoxuKW8zpoYP5hFAnvFzSWgw0AFPv7BfbPS
nHvVc8KJ6KkRJEFofcDBcA0oO88XoAG47JXA2YhS7WWE4yKkBm/Hvhv4z3FSTa3a
z6qhv9aSINyHXsSnIqyuy8kVwIzBMSbB70Nn0DSKu93PHgWxlgmOXopUCBlUgkeC
i5FxxxZ4W4kDnlrrBH7ctjeHBkIWRBX6LUCogQ9x/sCPjIvipBzfvA+LxYQkmoIx
HBmKQshaeMAkEnwIQhv4l3jSpUVAedZr4/bfE7dyxKtZBWTiaOKTr62kMKzIWU6O
XdB5/FbRzSFSXXl+KzxR1l9R6H/vAn1PH16X+3ZBkJdapTGOHsx4q8lYQVwvHCfi
yo6GNdEPVds095pci5+LRj8yeDURP2Mp3xQX7t49AEg3BafznnB37LXyOWev8ZSr
gd83huZO/yYvktoptTLWQ1t2x/KJSwQ2m5yk/Jj6AMPQN43LzdqO1USAbHrflYON
NEi4DcXktkHCBahbfPP6eRyObO5KTLK10z6bFjRtpX3TmXm1O9g7jTMt6zQPYKUH
77/7+ON5vJrKMS5CgaXv
=vEi+
-END PGP SIGNATURE-

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 11 de noviembre de 2016 16:05:49 ART Jan Niehusmann wrote:
> On Fri, Nov 11, 2016 at 03:15:09PM +0100, Kurt Roeckx wrote:
> > At least something like that also came up with xmltooling.
> > It's probably caused by this:
> > curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, _cb);
> > 
> > You get an SSL_CTX from OpenSSL 1.1 and you call an OpenSSL 1.0
> > function with that handle. And libcurl really shouldn't have been
> > exposing such functions directly. If something like that is
> > really needed libcurl should have made a proper wrapper.
> 
> Yes, I agree that libcurl shouldn't expose such functions. But it does,
> and it's to late to change that.
> 
> By exposing that function, SSL_CTX became part of curl's ABI.
> 
> So by linking to a different OpenSSL version with a different
> representation of SSL_CTX, curl indeed changed its ABI and must
> change SONAME, right?

That or switching it's B-D to libssl1.0-dev to avoid the breackage, but yes, 
you are right.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 1.1.0

[Jan Niehusmann]

On Fri, Nov 11, 2016 at 03:15:09PM +0100, Kurt Roeckx wrote:
> At least something like that also came up with xmltooling.
> It's probably caused by this:
> curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, _cb);
> 
> You get an SSL_CTX from OpenSSL 1.1 and you call an OpenSSL 1.0
> function with that handle. And libcurl really shouldn't have been
> exposing such functions directly. If something like that is
> really needed libcurl should have made a proper wrapper.

Yes, I agree that libcurl shouldn't expose such functions. But it does,
and it's to late to change that.

By exposing that function, SSL_CTX became part of curl's ABI.

So by linking to a different OpenSSL version with a different
representation of SSL_CTX, curl indeed changed its ABI and must
change SONAME, right?

Jan

Re: OpenSSL 1.1.0

[Kurt Roeckx]

On Fri, Nov 11, 2016 at 01:23:31PM +0100, Jan Niehusmann wrote:
> Hi,
> 
> But who knows which other packages are silently broken the same way?

At least something like that also came up with xmltooling.
It's probably caused by this:
curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, _cb);

You get an SSL_CTX from OpenSSL 1.1 and you call an OpenSSL 1.0
function with that handle. And libcurl really shouldn't have been
exposing such functions directly. If something like that is
really needed libcurl should have made a proper wrapper.

PS: Is there a reason zurl implements it's own hostname validation
checking an doesn't just use libcurls?


Kurt

Re: OpenSSL 1.1.0

[Jan Niehusmann]

Hi,

(Cc to Alessandro because this causes issues with libcurl)

On Wed, Nov 02, 2016 at 09:15:13PM +0100, Kurt Roeckx wrote:
> I don't think having libssl1-1-dev vs libssl1.0-dev is going to
> make much differences in the end. The build conflicts will always
> have to be sorted out.

Well I think it makes a difference:

With libssl-dev silently switching to OpenSSL 1.1, packages get
recompiled with the new version, but the maintainers may be unaware that
this causes compatibility issues.

I have a concrete example:

It seems like the package zurl is broken by libcurl3 being linked with
OpenSSL 1.1.

This means the binary package zurl 1.7.0-1 works fine with libcurl3
7.50.1-1, but fails to connect to https URLs when libcurl3 is upgraded
to 7.51.0-1.

(It also works with curl 7.51.0-1 recompiled with OpenSSL 1.0, so I'm
quite sure it's actually caused by the OpenSSL transition.)

So, in short, upgrading libcurl3 breaks existing binary packages.

According to our policy, that means a SONAME change would be necessary.
("Every time the shared library ABI changes in a way that may break
binaries linked against older versions of the shared library, the SONAME
of the library and the corresponding name for the binary package
containing the runtime shared library should change.")

But the way the OpenSSL transition was communicated, Alessando probably
didn't expect that the change would cause an ABI change.

How do we handle this?

For this single package, zurl, I could recompile with OpenSSL 1.1. This
seems to work, but I'm not sure if there are hidden issues, as zurl also
links to qt5, which is built against libssl1.0-dev.

But who knows which other packages are silently broken the same way?

Jan

Re: OpenSSL 1.1.0

[Jan Niehusmann]

Hi,

On Fri, Nov 04, 2016 at 11:58:44PM +0200, Adrian Bunk wrote:
> You could enforce that no Qt-using package uses the wrong OpenSSL by 
> adding libssl1.0-dev dependencies to libqt4-dev and qtbase5-dev.

How can I handle the case of a package which uses both qt and curl? The
latter already switched to OpenSSL 1.1.

Jan

Re: OpenSSL 1.1.0

[Gert Wollny]

You could enforce that no Qt-using package uses the wrong OpenSSL by
> adding libssl1.0-dev dependencies to libqt4-dev and qtbase5-dev.
>
> After that, trying to compile any Qt-using package with the wrong 
> OpenSSL should fail due to unsatisfiable build dependencies.
>
>
Well, if a library A uses openssl, but doesn't expose this use through
its header files (e.g. because it also loads openssl dynamically), then
libA-dev doesn't require to depend on any libssl*-dev library, i.e. one
would also have to manually add the otherwise not needed libssl*-dev
dependency.   
For instance I think that gdcm also loads openssl dynamically.

To keep a record: because itksnap uses QT5, dcmtk,  and gdcm, the latter
two libraries will be build against openssl-1.0.

Best,
Gert




signature.asc
Description: OpenPGP digital signature

Re: OpenSSL 1.1.0

[James Cloos]

Is anyone keeping track of when the various packages which depend on
openssl expect to upload versions compiled against 1.1?

I'd like to take advantage of x25519 and chacha20-poly1305 for various
tls-using servers...

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Re: OpenSSL 1.1.0

[Adrian Bunk]

On Thu, Nov 03, 2016 at 10:49:30AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On jueves, 3 de noviembre de 2016 12:34:23 P. M. ART Tino Mettler wrote:
> > On Wed, Nov 02, 2016 at 14:02:52 -0300, Lisandro Damián Nicanor Pérez Meyer
> > wrote:
> > 
> > [...]
> > 
> > > Today we the Qt/KDE team were hit but this same thing in the middle of our
> > > transition: libpq-dev pulls in libssl-dev which makes Qt5 FTBFS.
> > 
> > Hi,
> > 
> > libqt staying at OpenSSL 1.0 means all binaries linking against libqt
> > need to stay at OpenSSL 1.0. Is this correct?
> 
> To the best of my knowledge yes, because Qt dllopens it and thus doesn't 
> resolves symbols versions.
> 
> Note that this is valid for both Qt4 and Qt5.

You could enforce that no Qt-using package uses the wrong OpenSSL by 
adding libssl1.0-dev dependencies to libqt4-dev and qtbase5-dev.

After that, trying to compile any Qt-using package with the wrong 
OpenSSL should fail due to unsatisfiable build dependencies.

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

Re: OpenSSL 1.1.0

[Colin Tuckley]

On 04/11/16 10:53, Pau Garcia i Quiles wrote:

> As I requested a few days ago, please delay making OpenSSL 1.1.0 the
> default for 1 year (and even then, we should be checking the case
> where something links directly to one version of OpenSSL, and also
> links to something that dlopen's some other version of OpenSSL).

I also agree with this. One of my (team maintained) packages uses
OpenSSL and upstream are working on support for the new version but they
say it will be a while before it's ready for release.

I don't know why this is being pushed so fast. It might be ready and the
maintainer might want it in the next Debian stable release but it seems
that most of the application users of OpenSSL are not ready for it and
*their* releases won't make the Debian release freeze deadline.

Colin

-- 
Colin Tuckley| +44(0)1223 830814 |  PGP/GnuPG Key Id
Debian Developer | +44(0)7799 143369 | 0xFA0C410738C9D903





signature.asc
Description: OpenPGP digital signature

Re: OpenSSL 1.1.0

[Pau Garcia i Quiles]

On Fri, Nov 4, 2016 at 1:43 AM, Ian Jackson
 wrote:


> I'm concerned that we are setting up a situation where:
>
>  * A maintainer (or interested party) for a package which peripherally
>uses openssl;
>  * Gets an RC bug report;
>  * Is threatened with autoremoval;
>  * Does not really know how to respond;
>  * Does not have useful support from their own upstream because
>their own upstream hasn't got to grips with this yet;
>  * Feels under pressure that they must Fix It Now.
>
> This seems to be setting ourselves up for failures - particularly,
> failures where the package compiles and seems to work, but has some
> kind of problem in its use of openssl APIs which constitutes a
> security problem.
>
[...]

I fully agree and I have been stating that for months.

In fact, yesterday I checked that my package witty now builds fine
with OpenSSL 1.1.0 thanks to a new version of Boost. But I suspect
there will be something wrong on runtime because witty does link to
Qt4, which as Lisandro said recently, does not support OpenSSL 1.1.0.
It may fail on runtime.

As I requested a few days ago, please delay making OpenSSL 1.1.0 the
default for 1 year (and even then, we should be checking the case
where something links directly to one version of OpenSSL, and also
links to something that dlopen's some other version of OpenSSL).

Thank you

-- 
Pau Garcia i Quiles
http://www.elpauer.org

Re: OpenSSL 1.1.0

[Ian Jackson]

Kurt Roeckx writes ("OpenSSL 1.1.0"):
> I just uploaded OpenSSL 1.1.0 to unstable. There are still many
> packages that fail to build using OpenSSL 1.1.0. For most packages
> it should be easy to migrate 1.1.0. The most common problems when
> going to OpenSSL 1.1.0 are:
> - configure trying to detect a function that's now a macro.
> - Accessing members of structures that have now become opaque. You
>   now need to use function to get or set them.

I'm concerned that we are setting up a situation where:

 * A maintainer (or interested party) for a package which peripherally
   uses openssl;
 * Gets an RC bug report;
 * Is threatened with autoremoval;
 * Does not really know how to respond;
 * Does not have useful support from their own upstream because
   their own upstream hasn't got to grips with this yet;
 * Feels under pressure that they must Fix It Now.

This seems to be setting ourselves up for failures - particularly,
failures where the package compiles and seems to work, but has some
kind of problem in its use of openssl APIs which constitutes a
security problem.

Maintainers who feel pressured may well apply patches which have not
had the level of review or discussion that would normally be
appropriate.  In security-sensitive code this is unfortunate.

There doesn't seem to be any way for a maintainer who is unsure to get
a review of a proposed patch to their package.  This is particularly
true when upstreams don't have patches - which seems to be true for
many packages (even BIND, say, only had them very recently).

Nor do we have any coherent tracking of what ad-hoc patches we are
(collectively) rushing to apply.

The use of RC bug status is a very strong imperative to maintainers.
I worry that we haven't really thought through the implications.

In general any large-scale transition like this needs to take into
account not only the technical goals, but also the best way to get the
best quality work out of our contributors.  I worry that the current
process is likely to encourage hasty actions.

If the process we have adopted results in security bugs, it will not
be enough to blame the poor maintainer who felt they had no
alternative.

Thanks for your attention.

Ian.

-- 
Ian Jackson    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.

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On jueves, 3 de noviembre de 2016 12:34:23 P. M. ART Tino Mettler wrote:
> On Wed, Nov 02, 2016 at 14:02:52 -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> 
> [...]
> 
> > Today we the Qt/KDE team were hit but this same thing in the middle of our
> > transition: libpq-dev pulls in libssl-dev which makes Qt5 FTBFS.
> 
> Hi,
> 
> libqt staying at OpenSSL 1.0 means all binaries linking against libqt
> need to stay at OpenSSL 1.0. Is this correct?

To the best of my knowledge yes, because Qt dllopens it and thus doesn't 
resolves symbols versions.

Note that this is valid for both Qt4 and Qt5.

-- 
UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity.
  Dennis Ritchie

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.