Re: openssl transition

[Adam Majer]

On 27/10/16 07:39 AM, Antti J ä rvinen wrote:

Jörg Frings-Fürst writes:

 > I have read the discussion about the openssl transition here again.

Possibly referring to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 ??

 > - The parallel use of release 1.0 and 1.1 will not be pursued?

Might be highly problematic, having purposefully 2 different versions
of the same library in same process isn't the brightest idea. Real
world example is any application that links openssl and qt library.
Should you link different openssl version than the one used by qt
will ..produce interesting results :)


Well, depends how they are used. OpenSSL has versioned symbols, so using 
binaries that are linked via both is not an issue. For example,


  a.out
- liba
   + openssl 1.0.2
- libb
   + openssl 1.1.0

should work fine.

The problem is that quite a bit of software probably uses OpenSSL via 
dlopen interface and not via linking. This could result in problems. Qt 
can be patched/rebuild to only look for the 1.0.2 library and resolve 
symbols there. What about other cases?


- Adam

Re: openssl transition

[Pau Garcia i Quiles]

On Thu, Oct 27, 2016 at 2:39 PM, Antti Järvinen 
wrote:


> While patching -DOPENSSL_API_COMPAT=0x1010L will help a lot but
> code changes are still required in addition to this flag, many
> applications allocate OpenSSL data-structures in stack and this is not
> supported any more, regardless of -DOPENSSL_API_COMPAT.
>
>
This whole "let's shove OpenSSL 1.1 down your throat" is a very bad idea,
IMHO.

My upstreams (witty and ace) have no plans to support OpenSSL 1.1 in the
next months.

I do not have enough knowledge with OpenSSL to feel comfortable with my
patches. I may end up rendering the software insecure.

Does anyone remember the OpenSSL PRNG incident 10 years ago? Are we trying
to repeat it?
https://www.schneier.com/blog/archives/2008/05/random_number_b.html

Really, this does look like a huge mistake. Packagers will produce patches
that will generate suboptimal, if not straight insecure, software just for
their packages not to be removed, and/or to stop those "hey hey, RC bug on
you!" mails. Please, delay the "only 1.1 migration" for 1 year.

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

Re: openssl transition

[Michael Meskes]

> Well, most upstreams will want to support OpenSSL 1.0 for a little
> while longer (lots of other distributions are still on OpenSSL 1.0
> for the foreseeable future), so any patch that has a chance of
> getting accepted by most upstreams will still need to support 1.0
> as well as 1.1.

True, but I wonder if this is the right basis for a transition plan.
Not saying you said it would be. I just question if there is one. Other
than removing everything that does not compile with 1.1 of course.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: openssl transition

[Christian Seiler]

On 10/30/2016 11:03 AM, Michael Meskes wrote:
> On Sat, Oct 29, 2016 at 10:04:21PM +0200, Christian Seiler wrote:
>> Well, ideally it'll compile with both OpenSSL 1.0.2 and 1.1 and
>> therefore be binNMU-able. (This has the advantage that such a
>> patch is much more likely to get accepted by upstream.) In that
>> case you can upload a version that Closes: #nnn the RC bug.
> 
> It turned out my packages were easy, they just needed OPENSSL_API_COMPAT to be
> defined accordingly. However, I don't think all upstreams will work like this.
> I can easily see some just requiring OpenSSL 1.1 and change the code
> accordingly. And I doubt it's wise for us to require packages to be patched to
> compile with the old version of OpenSSL, too.

Well, most upstreams will want to support OpenSSL 1.0 for a little
while longer (lots of other distributions are still on OpenSSL 1.0
for the foreseeable future), so any patch that has a chance of
getting accepted by most upstreams will still need to support 1.0
as well as 1.1.

I'm not saying this should be a hard requirement in Debian itself
(I did say "ideally" in my initial reply), but I do think that if
you're touching the code anyway, it's worthwhile to at least
consider that.

>> (Also, if you ever want to backport stuff to jessie-backports, it
>> is necessary to still support building against OpenSSL 1.0 even
>> after the transition. That's not something relevant for all
>> packages, as not everything is going to be backported, but there
>> are definitely some packages that will be affected.)
> 
> What prevents us from backporting OpenSSL?

In principle nothing (once it's in testing, of course), but since
OpenSSL is very security-critical in terms of impact on the number
of packages affected (and there are frequent security updates),
the person doing the backports would have to be _very_ on top of
this for this to work reasonably well. I'm not saying this isn't
going to happen, but you'd need to have someone who'd actually
be willing to make that kind of commitment. Making a package that
you want to backport compile with both 1.1 and 1.0 is probably
less work than maintaining a backport of OpenSSL 1.1.

Regards,
Christian

Re: openssl transition

[Michael Meskes]

On Sat, Oct 29, 2016 at 10:04:21PM +0200, Christian Seiler wrote:
> Well, ideally it'll compile with both OpenSSL 1.0.2 and 1.1 and
> therefore be binNMU-able. (This has the advantage that such a
> patch is much more likely to get accepted by upstream.) In that
> case you can upload a version that Closes: #nnn the RC bug.

It turned out my packages were easy, they just needed OPENSSL_API_COMPAT to be
defined accordingly. However, I don't think all upstreams will work like this.
I can easily see some just requiring OpenSSL 1.1 and change the code
accordingly. And I doubt it's wise for us to require packages to be patched to
compile with the old version of OpenSSL, too.

> (Also, if you ever want to backport stuff to jessie-backports, it
> is necessary to still support building against OpenSSL 1.0 even
> after the transition. That's not something relevant for all
> packages, as not everything is going to be backported, but there
> are definitely some packages that will be affected.)

What prevents us from backporting OpenSSL?

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: openssl transition

[Christian Seiler]

On 10/29/2016 09:27 PM, Michael Meskes wrote:
>> - The parallel use of release 1.0 and 1.1 will not be pursued?
>>
>> - Why is the transition started with 0 (zero) good packages (from
> 552)?
>> ... 
> 
> May I add one more, and actually pretty pressing question? How are we
> supposed to upload "fixed" packages?
> 
> I have two that are said to be removed in, like, 12 days. If I upload
> those to experimental, it will not prevent the auto-removal. Uploading
> to sid will make the packages uninstallable for obvious reasons. And
> then there's the "transition freeze" in 7 days.
> 
> Let's say I'm a bit confused. Could anyone please tell me how this is
> supposed to be handled?

Well, ideally it'll compile with both OpenSSL 1.0.2 and 1.1 and
therefore be binNMU-able. (This has the advantage that such a
patch is much more likely to get accepted by upstream.) In that
case you can upload a version that Closes: #nnn the RC bug.

When I initially packaged open-isns I did have the looming OpenSSL
transition on my mind, so I added a to makes open-isns build
against both 1.0 and 1.0.2 (and also 1.0.1, for backporting to
Jessie) before the very first upload to sid. Once the SSL
transition gets started, the release team will just have to
binNMU the package once openssl 1.1 is uploaded to sid.
(Also, if you ever want to backport stuff to jessie-backports, it
is necessary to still support building against OpenSSL 1.0 even
after the transition. That's not something relevant for all
packages, as not everything is going to be backported, but there
are definitely some packages that will be affected.)

If you're interested in how that can look like:
https://anonscm.debian.org/cgit/pkg-iscsi/open-isns.git/tree/debian/patches/openssl-1.1.patch
The patch is about the same complexity as a (hypothetical) patch
that just makes the software compile against 1.1 whilst dropping
support for 1.0.  Granted, open-isns is not a heavy user of
OpenSSL, so YMMV here.

Regards,
Christian

Re: openssl transition

[Michael Meskes]

> - The parallel use of release 1.0 and 1.1 will not be pursued?
>
> - Why is the transition started with 0 (zero) good packages (from
552)?
> ... 

May I add one more, and actually pretty pressing question? How are we
supposed to upload "fixed" packages?

I have two that are said to be removed in, like, 12 days. If I upload
those to experimental, it will not prevent the auto-removal. Uploading
to sid will make the packages uninstallable for obvious reasons. And
then there's the "transition freeze" in 7 days.

Let's say I'm a bit confused. Could anyone please tell me how this is
supposed to be handled?

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: openssl transition

[Ian Jackson]

Jonas Smedegaard writes ("Re: openssl transition"):
> Quoting Ian Jackson (2016-10-28 01:00:25)
> > I keep meaning to try to find a way to figure out what package(s) it 
> > might be, that isn't eyeballing the list.
> 
> Try check the email headers - in my experience often there is am 
> X-somethind line added hinting about the specific package.

I looked at the email headers again and found that indeed in between
the huge X- header listing package names, and the To header listing
email addresese none of which were mine, were a bunch of headers
showing it had come via socat@packages.q.d.o.

Thanks for jolting me out being stuck!

Regards,
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 transition

[Jonas Smedegaard]

Quoting Ian Jackson (2016-10-28 01:00:25)
> Russ Allbery writes ("Re: openssl transition"):
> > The release team asked for all the OpenSSL bugs to be upgraded to 
> > RC, which is probably what triggered this discussion.  (I was a bit 
> > surprised too; that's quite a lot of packages to yank from testing 
> > by the middle of next month for problems that will often require 
> > upstream fixes.  But hey, it does get people motivated, and it's 
> > certainly increased my motivation to work out a fix for a 
> > quasi-orphaned package I still maintain, sort of.)
> 
> I got a copy of the mail fom the BTS about this but I still haven't 
> figured out which package it relates to :-/.  I worry that I have 
> subscribed to a package in an incomplete way (ddpo only or maybe bts 
> only) and it's going to be removed and I will notice too late...
> 
> I keep meaning to try to find a way to figure out what package(s) it 
> might be, that isn't eyeballing the list.

Try check the email headers - in my experience often there is am 
X-somethind line added hinting about the specific package.


 - Jonas

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

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


signature.asc
Description: signature

Re: openssl transition

[Ian Jackson]

Russ Allbery writes ("Re: openssl transition"):
> The release team asked for all the OpenSSL bugs to be upgraded to RC,
> which is probably what triggered this discussion.  (I was a bit surprised
> too; that's quite a lot of packages to yank from testing by the middle of
> next month for problems that will often require upstream fixes.  But hey,
> it does get people motivated, and it's certainly increased my motivation
> to work out a fix for a quasi-orphaned package I still maintain, sort of.)

I got a copy of the mail fom the BTS about this but I still haven't
figured out which package it relates to :-/.  I worry that I have
subscribed to a package in an incomplete way (ddpo only or maybe bts
only) and it's going to be removed and I will notice too late...

I keep meaning to try to find a way to figure out what package(s) it
might be, that isn't eyeballing the list.

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 transition

[Russ Allbery]

Dimitri John Ledkov  writes:

> However no transition has started. Transitions only start once the new
> ABI is uploaded into unstable, which has not happened.

The release team asked for all the OpenSSL bugs to be upgraded to RC,
which is probably what triggered this discussion.  (I was a bit surprised
too; that's quite a lot of packages to yank from testing by the middle of
next month for problems that will often require upstream fixes.  But hey,
it does get people motivated, and it's certainly increased my motivation
to work out a fix for a quasi-orphaned package I still maintain, sort of.)

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

Re: openssl transition

[Antti Järvinen]

Jörg Frings-Fürst writes:

 > I have read the discussion about the openssl transition here again.

Possibly referring to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 ??

 > - The parallel use of release 1.0 and 1.1 will not be pursued?

Might be highly problematic, having purposefully 2 different versions
of the same library in same process isn't the brightest idea. Real 
world example is any application that links openssl and qt library. 
Should you link different openssl version than the one used by qt 
will ..produce interesting results :)

LibreOffice comes to my mind next, it pulls openssl via number of
different libraries like database drivers. 

While patching -DOPENSSL_API_COMPAT=0x1010L will help a lot but
code changes are still required in addition to this flag, many
applications allocate OpenSSL data-structures in stack and this is not
supported any more, regardless of -DOPENSSL_API_COMPAT.

--
Antti

Re: openssl transition

[Dimitri John Ledkov]

Hello,

On 27 October 2016 at 11:40, Jörg Frings-Fürst
<deb...@jff-webhosting.net> wrote:
> Hello,
>
> I have read the discussion about the openssl transition here again.
>
> One of the last notes was to be used openssl 1.0 and 1.1 in parallel
> because of the non-trivial changes.
>
> So I have some questions:
>
> - The parallel use of release 1.0 and 1.1 will not be pursued?
>
> - Why is the transition started with 0 (zero) good packages (from 552)?
>

I do not see that a transition has started.

There are bug reports tagged for the transition:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=openssl-1.1-trans=pkg-openssl-devel-request%40lists.alioth.debian.org
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=openssl-1.1-trans-keypkg=pkg-openssl-devel-request%40lists.alioth.debian.org

There is 1.1 openssl in experimental:
https://tracker.debian.org/pkg/openssl

This did trigger an automated transition tracker to be created:
https://release.debian.org/transitions/html/auto-openssl.html

But do note that "This tracker was setup by a very simple automated
tool. The tool may not be very smart..."

However no transition has started. Transitions only start once the new
ABI is uploaded into unstable, which has not happened.

> - Should it be safer to switch to a new API at short notice and
> under  pressure?
>
>
> CU
> Jörg
> --
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key: 8CA1D25D
> CAcert Key S/N : 0E:D4:56
>
> Old pgp Key: BE581B6E (revoked since 2014-12-31).
>
> Jörg Frings-Fürst
> D-54470 Lieser
>
> Threema: SYR8SJXB
>
> IRC: j_...@freenode.net
>  j_...@oftc.net
>
> My wish list:
>  - Please send me a picture from the nature at your home.



-- 
Regards,

Dimitri.

openssl transition

[Jörg Frings-Fürst]

Hello,

I have read the discussion about the openssl transition here again. 

One of the last notes was to be used openssl 1.0 and 1.1 in parallel
because of the non-trivial changes.

So I have some questions:

- The parallel use of release 1.0 and 1.1 will not be pursued?

- Why is the transition started with 0 (zero) good packages (from 552)?

- Should it be safer to switch to a new API at short notice and
under  pressure? 


CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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