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 AS
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
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 fo
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 n
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 t
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 onl
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 o
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 m
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 t
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 lea
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 cat
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",
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
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?
AFA
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 rel
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
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 unfortun
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 Zeimetz
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 t
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 whol
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
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
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 ge
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.
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 al
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
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
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?
--
Be
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 AP
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
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 wil
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
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
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 chan
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
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 relea
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
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
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
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
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 Op
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:
>
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
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 (
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.
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
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
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 transitio
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 onl
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 o
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.debia
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 M
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 de
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 h
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
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
OpenSS
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.
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.
--
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 lik
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
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
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 b
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 startu
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.deb
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
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 JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a
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
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
> > >
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 c
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
> >
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
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
> tow
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
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
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 f
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
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 sw
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 in
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 Cha
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
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
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
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 nex
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.
>
>
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
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,
f
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
-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 in
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, &sslCtxFunction
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, &sslCtxFunction_cb);
>
> You get an SSL_CTX from OpenSSL 1.1 and you call an OpenSSL 1.0
> fu
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, &sslCtxFunction_
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
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 switch
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
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
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 t
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 othe
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 ho
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 dete
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
1 - 100 of 129 matches
Mail list logo
