Road to new openssl

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Road to new openssl

Dimitri John Ledkov
openssl has changed api/abi. Currently Ubuntu ships 1.0.2 LTS series
openssl. Newer api/abi is available as a non-lts 1.1.0 series. Both
1.0.2 and 1.1.0 series will go end of life upstream over the lifetime
of bionic.

TLS 1.3 is currently undergoing standardisation
(https://github.com/tlswg/tls13-spec) But it seems like it is still
being actively iterated on.

The next openssl series is expected to be 1.1.1 and it should be
binary compatible with 1.1.0 series. And 1.1.1 series are expected to
be released with TLS 1.3 support, after it is finalised and published.

In Ubuntu, we would want to avoid shipping two openssl series
simultaneously. Or at least avoid having two series in main.

I have rebuild openssl 1.1.0 package from debian, with modifications
to force provide all -dev packages pointint at 1.1.0 series, to
validate how many outstanding packages in main still do not support
1.1.0 series api/abi in bionic in main.

The failed build logs for main can be seen here:
https://launchpad.net/~xnox/+archive/ubuntu/openssl/+packages?field.name_filter=&field.status_filter=published&field.series_filter=bionic

These are:
 bind9
 freerdp
 linux
 nagios-nrpe
 net-snmp
 openhpi
 openssh
 pam-p11
 ppp
 qtbase-opensource-src
 ruby2.3
 wpa
 wvstreams
 xchat-gnome

Thus there are 14 packages to fix.

Of which
- ruby2.5 supports the new abi, and it is expected there will be 2.5
transition in Debian/Ubuntu soon
- Qt 5.10 has new abi support, and there is backport branch/patch that
applies to 5.9 series
- openssh is being worked on and is complex, I am hoping for this
solution to work out
https://github.com/openssh/openssh-portable/pull/48
- linux is an unidentified failure, maybe a generic FTBFS

Meaning 10 packages are in the unknown state of progress. I'm not sure
if it is feasible to switch to 1.1.0 openssl without all of the above
packages fixed to work with the new API.

Feel free to use openssl from the above PPA for test builds only, as
it is entirely unsupported PPA and may go away at any point.
It is not compatible with neither Ubuntu or Debian nor ever will be,
due to overriding of the meta-package to point at 1.1.0 series openssl
unconditionally.

Timeline:

* I hope that TLS WG can standartise TLS 1.3 soon

* I hope that OpenSSL team can release 1.1.1 series with TLS 1.3. soon
and declare it LTS series

* Or at least I hope that OpenSSL team could consider extending 1.1.0
series security support timeframe

.... so I wish all that for Christmas or a unicorn. I fear, I may end
up with a unicorn.

--
Regards,

Dimitri.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Colin Watson
On Tue, Dec 12, 2017 at 03:59:50PM +0000, Dimitri John Ledkov wrote:
> - openssh is being worked on and is complex, I am hoping for this
> solution to work out
> https://github.com/openssh/openssh-portable/pull/48

Upstream is not happy with this, and it's unlikely to be quite what we
end up with.  The threads starting at these points (they got a bit split
up in the archives) are more up to date:

  https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html
  https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036376.html
  https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-November/036467.html

At this point I cannot say with any particular confidence whether
OpenSSH will be ready for this transition by 18.04, although it can cope
with the current situation in Debian unstable where the default is 1.1
but 1.0 is also available.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Steve Langasek-6
In reply to this post by Dimitri John Ledkov
On Tue, Dec 12, 2017 at 03:59:50PM +0000, Dimitri John Ledkov wrote:

> openssl has changed api/abi. Currently Ubuntu ships 1.0.2 LTS series
> openssl. Newer api/abi is available as a non-lts 1.1.0 series. Both
> 1.0.2 and 1.1.0 series will go end of life upstream over the lifetime
> of bionic.
>
> TLS 1.3 is currently undergoing standardisation
> (https://github.com/tlswg/tls13-spec) But it seems like it is still
> being actively iterated on.
>
> The next openssl series is expected to be 1.1.1 and it should be
> binary compatible with 1.1.0 series. And 1.1.1 series are expected to
> be released with TLS 1.3 support, after it is finalised and published.
>
> In Ubuntu, we would want to avoid shipping two openssl series
> simultaneously. Or at least avoid having two series in main.
>
> I have rebuild openssl 1.1.0 package from debian, with modifications
> to force provide all -dev packages pointint at 1.1.0 series, to
> validate how many outstanding packages in main still do not support
> 1.1.0 series api/abi in bionic in main.
>
> The failed build logs for main can be seen here:
> https://launchpad.net/~xnox/+archive/ubuntu/openssl/+packages?field.name_filter=&field.status_filter=published&field.series_filter=bionic
>
> These are:
>  bind9
Fixed in Debian unstable; Server Team will merge it this cycle.

>  freerdp

Fix available upstream: https://github.com/FreeRDP/FreeRDP/issues/3098

>  linux
>  nagios-nrpe

Looks like we have an Ubuntu delta for OpenSSL 1.0 compatibility which could
be easily dropped
(https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/1715167)

>  net-snmp

Patch available in Debian BTS, was deferred for stretch:
https://bugs.debian.org/828449

>  openhpi

Debian bug, no patch: https://bugs.debian.org/859543

>  openssh

As discussed.

>  pam-p11

Debian bug, no patch: https://bugs.debian.org/871939
Upstream issue open: https://github.com/OpenSC/pam_p11/issues/6

>  ppp

Ubuntu-specific build failure due to non-upstreamed eap-tls patch.  Patch
author has new version of patch available at
https://www.nikhef.nl/~janjust/ppp/download.html for OpenSSL 1.1.

>  qtbase-opensource-src
>  ruby2.3
>  wpa

New version available in Debian unstable with support for openssl 1.1.

>  wvstreams

Debian bug, no patch: https://bugs.debian.org/859791
Unclear where the current 4.6.1 release originated from, the packaging
points to https://github.com/apenwarr/wvstreams for the upstream but this
has 4.3 as the last upstream release in 2010 and no commits since 2010.
wvstreams is in main for wvdial, seeded on the live image, a decision last
reviewed in 2010
(https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/400573).  This
should probably be reviewed for 18.04.

>  xchat-gnome

Ubuntu-only package (dropped in Debian, dropped subsequently in Ubuntu, then
brought back).  Did not ship in yakkety or zesty; when restored in artful it
went straight to main because it was still seeded, but it's unclear this was
ever reviewed by the Desktop Team or whether they want this package still in
main.  (The re-uploader is not a member of the Desktop Team.)


> Thus there are 14 packages to fix.
>
> Of which
> - ruby2.5 supports the new abi, and it is expected there will be 2.5
> transition in Debian/Ubuntu soon
> - Qt 5.10 has new abi support, and there is backport branch/patch that
> applies to 5.9 series
> - openssh is being worked on and is complex, I am hoping for this
> solution to work out
> https://github.com/openssh/openssh-portable/pull/48
> - linux is an unidentified failure, maybe a generic FTBFS
>
> Meaning 10 packages are in the unknown state of progress. I'm not sure
> if it is feasible to switch to 1.1.0 openssl without all of the above
> packages fixed to work with the new API.
>
> Feel free to use openssl from the above PPA for test builds only, as
> it is entirely unsupported PPA and may go away at any point.
> It is not compatible with neither Ubuntu or Debian nor ever will be,
> due to overriding of the meta-package to point at 1.1.0 series openssl
> unconditionally.
>
> Timeline:
>
> * I hope that TLS WG can standartise TLS 1.3 soon
>
> * I hope that OpenSSL team can release 1.1.1 series with TLS 1.3. soon
> and declare it LTS series
>
> * Or at least I hope that OpenSSL team could consider extending 1.1.0
> series security support timeframe
>
> .... so I wish all that for Christmas or a unicorn. I fear, I may end
> up with a unicorn.
There are still some unresolved upstream porting issues, and openssh is
certainly the big one.  But it looks like the upstream TLS 1.3
standardization is the main blocker.

Thanks,
--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Jeremy Bicha-2
In reply to this post by Dimitri John Ledkov
On Tue, Dec 12, 2017 at 10:59 AM, Dimitri John Ledkov <[hidden email]> wrote:
>  freerdp

freerdp is no longer in main. freerdp2 should work fine with openssl 1.1

Thanks,
Jeremy Bicha

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Marc Deslauriers-3
In reply to this post by Dimitri John Ledkov
On 2017-12-12 10:59 AM, Dimitri John Ledkov wrote:

> openssl has changed api/abi. Currently Ubuntu ships 1.0.2 LTS series
> openssl. Newer api/abi is available as a non-lts 1.1.0 series. Both
> 1.0.2 and 1.1.0 series will go end of life upstream over the lifetime
> of bionic.
>
> TLS 1.3 is currently undergoing standardisation
> (https://github.com/tlswg/tls13-spec) But it seems like it is still
> being actively iterated on.
>
> The next openssl series is expected to be 1.1.1 and it should be
> binary compatible with 1.1.0 series. And 1.1.1 series are expected to
> be released with TLS 1.3 support, after it is finalised and published.
>
> In Ubuntu, we would want to avoid shipping two openssl series
> simultaneously. Or at least avoid having two series in main.

When we did the switch from 0.9.8 to 1.0.0, we kept 0.9.8 in universe, and that
was a big mistake. Third party applications and a whole slew of commonly-used
software from universe were using a version of ssl that didn't get any security
fixes. It was such a problem that we had to half-maintain it anyway until we
were no longer able to.

I do not wish to repeat that experience if possible, especially for an LTS
version of Ubuntu we'll need to support for 5 years. If we do switch to 1.1, I
would prefer 1.0.2 get removed from universe.

Have you done a test rebuild of universe packages?

>
> I have rebuild openssl 1.1.0 package from debian, with modifications
> to force provide all -dev packages pointint at 1.1.0 series, to
> validate how many outstanding packages in main still do not support
> 1.1.0 series api/abi in bionic in main.
>
> The failed build logs for main can be seen here:
> https://launchpad.net/~xnox/+archive/ubuntu/openssl/+packages?field.name_filter=&field.status_filter=published&field.series_filter=bionic
>
> These are:
>  bind9
>  freerdp
>  linux
>  nagios-nrpe
>  net-snmp
>  openhpi
>  openssh
>  pam-p11
>  ppp
>  qtbase-opensource-src
>  ruby2.3
>  wpa
>  wvstreams
>  xchat-gnome
>
> Thus there are 14 packages to fix.
>
> Of which
> - ruby2.5 supports the new abi, and it is expected there will be 2.5
> transition in Debian/Ubuntu soon
> - Qt 5.10 has new abi support, and there is backport branch/patch that
> applies to 5.9 series
> - openssh is being worked on and is complex, I am hoping for this
> solution to work out
> https://github.com/openssh/openssh-portable/pull/48
> - linux is an unidentified failure, maybe a generic FTBFS
>
> Meaning 10 packages are in the unknown state of progress. I'm not sure
> if it is feasible to switch to 1.1.0 openssl without all of the above
> packages fixed to work with the new API.
>
> Feel free to use openssl from the above PPA for test builds only, as
> it is entirely unsupported PPA and may go away at any point.
> It is not compatible with neither Ubuntu or Debian nor ever will be,
> due to overriding of the meta-package to point at 1.1.0 series openssl
> unconditionally.
>
> Timeline:
>
> * I hope that TLS WG can standartise TLS 1.3 soon
>
> * I hope that OpenSSL team can release 1.1.1 series with TLS 1.3. soon
> and declare it LTS series
>
> * Or at least I hope that OpenSSL team could consider extending 1.1.0
> series security support timeframe

This is the big issue. If upstream don't declare the 1.1 series to be their next
LTS series, we'll be shipping an interim release which could possibly be
different enough to both 1.0.2 and a future 1.2 that would prevent us from being
able to maintain it properly. Unless we get assurance from upstream that 1.1
will be the next LTS, I'd much rather we stay on 1.0.2 which will be supported
for a longer period.

>
> .... so I wish all that for Christmas or a unicorn. I fear, I may end
> up with a unicorn.
>

Can we task the unicorn with backporting openssl fixes? :)

Marc.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Dimitri John Ledkov
On 12 December 2017 at 23:15, Marc Deslauriers
<[hidden email]> wrote:

> On 2017-12-12 10:59 AM, Dimitri John Ledkov wrote:
>> openssl has changed api/abi. Currently Ubuntu ships 1.0.2 LTS series
>> openssl. Newer api/abi is available as a non-lts 1.1.0 series. Both
>> 1.0.2 and 1.1.0 series will go end of life upstream over the lifetime
>> of bionic.
>>
>> TLS 1.3 is currently undergoing standardisation
>> (https://github.com/tlswg/tls13-spec) But it seems like it is still
>> being actively iterated on.
>>
>> The next openssl series is expected to be 1.1.1 and it should be
>> binary compatible with 1.1.0 series. And 1.1.1 series are expected to
>> be released with TLS 1.3 support, after it is finalised and published.
>>
>> In Ubuntu, we would want to avoid shipping two openssl series
>> simultaneously. Or at least avoid having two series in main.
>
> When we did the switch from 0.9.8 to 1.0.0, we kept 0.9.8 in universe, and that
> was a big mistake. Third party applications and a whole slew of commonly-used
> software from universe were using a version of ssl that didn't get any security
> fixes. It was such a problem that we had to half-maintain it anyway until we
> were no longer able to.
>

openssh needs libcrypto only, I do wonder if we can bastardise 1.0.2
packaging to provide libcrypto only, despite shipping sources to build
everything.
I have not made assesment on how many things need libcrypto alone
without libssl1.0.

> I do not wish to repeat that experience if possible, especially for an LTS
> version of Ubuntu we'll need to support for 5 years. If we do switch to 1.1, I
> would prefer 1.0.2 get removed from universe.
>

As far as I understand the current openssl master is positioned to be
released as a 1.1.1 series, api/abi non-breaking w.r.t. to the current
stable 1.1.0 series.
At one point master did have abi breaks and marked as 1.2, but that
was reverted / fixed up.
But obviously this can change, as it has not been released.
Based on the upstream timings I think they are free to announce next
LTS release and/or change maintenance windows late 2018 or in 2019.

Apart from TLS 1.3, we are missing hw acceleration work that got added
in 1.1.0+ on multiple server architectures.

> Have you done a test rebuild of universe packages?
>

No, but I can do one locally and sync build logs.

>>
>> I have rebuild openssl 1.1.0 package from debian, with modifications
>> to force provide all -dev packages pointint at 1.1.0 series, to
>> validate how many outstanding packages in main still do not support
>> 1.1.0 series api/abi in bionic in main.
>>
>> The failed build logs for main can be seen here:
>> https://launchpad.net/~xnox/+archive/ubuntu/openssl/+packages?field.name_filter=&field.status_filter=published&field.series_filter=bionic
>>
>> These are:
>>  bind9
>>  freerdp
>>  linux
>>  nagios-nrpe
>>  net-snmp
>>  openhpi
>>  openssh
>>  pam-p11
>>  ppp
>>  qtbase-opensource-src
>>  ruby2.3
>>  wpa
>>  wvstreams
>>  xchat-gnome
>>
>> Thus there are 14 packages to fix.
>>
>> Of which
>> - ruby2.5 supports the new abi, and it is expected there will be 2.5
>> transition in Debian/Ubuntu soon
>> - Qt 5.10 has new abi support, and there is backport branch/patch that
>> applies to 5.9 series
>> - openssh is being worked on and is complex, I am hoping for this
>> solution to work out
>> https://github.com/openssh/openssh-portable/pull/48
>> - linux is an unidentified failure, maybe a generic FTBFS
>>
>> Meaning 10 packages are in the unknown state of progress. I'm not sure
>> if it is feasible to switch to 1.1.0 openssl without all of the above
>> packages fixed to work with the new API.
>>
>> Feel free to use openssl from the above PPA for test builds only, as
>> it is entirely unsupported PPA and may go away at any point.
>> It is not compatible with neither Ubuntu or Debian nor ever will be,
>> due to overriding of the meta-package to point at 1.1.0 series openssl
>> unconditionally.
>>
>> Timeline:
>>
>> * I hope that TLS WG can standartise TLS 1.3 soon
>>
>> * I hope that OpenSSL team can release 1.1.1 series with TLS 1.3. soon
>> and declare it LTS series
>>
>> * Or at least I hope that OpenSSL team could consider extending 1.1.0
>> series security support timeframe
>
> This is the big issue. If upstream don't declare the 1.1 series to be their next
> LTS series, we'll be shipping an interim release which could possibly be
> different enough to both 1.0.2 and a future 1.2 that would prevent us from being
> able to maintain it properly. Unless we get assurance from upstream that 1.1
> will be the next LTS, I'd much rather we stay on 1.0.2 which will be supported
> for a longer period.
>

Note that 1.1.1 and 1.1.0 are binary compatible, yet are treated as
separate series and can have different support time lines.

>>
>> .... so I wish all that for Christmas or a unicorn. I fear, I may end
>> up with a unicorn.
>>
>
> Can we task the unicorn with backporting openssl fixes? :)
>

But seriously, can we estimate how much contracting such a unicorn
would cost? And if we can justify it?

Also note, I do not know the status of 1.1.0/1.1.1 series FIPS patches
progress which may be a one more spanner in the works.

Regards,

Dimitri.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Dimitri John Ledkov
In reply to this post by Marc Deslauriers-3
On 12 December 2017 at 23:15, Marc Deslauriers
<[hidden email]> wrote:
> On 2017-12-12 10:59 AM, Dimitri John Ledkov wrote:
>
> Have you done a test rebuild of universe packages?
>

I've searched for binary packages with revere-dependencies of libssl
in universe; resolve source package names; and rebuild that.
Given that sources published in main may split publish some binaries
into universe, there are some duplicates/overlap with main.

I was expecting to rebuild 503 packages, but only 489 were attempted.
Preliminary results are:

$ grep -ah '^Status: [a-z]' *.build | sort | uniq -c
    122 Status: failed
      4 Status: skipped
    363 Status: successful

I suspect actual true failures to be lower; as a few things were not
bootstrapped in order, and this is just a first pass of rebuild
everything - once, disregarding build orderings.
It hopefully is representative of the efforts required to remove
openssl 1.0.2 series from the archive.

Regards,

Dimitri.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Andreas Hasenack-5
In reply to this post by Steve Langasek-6

>  net-snmp

Patch available in Debian BTS, was deferred for stretch:
https://bugs.debian.org/828449


5.7.3+dfsg-1.8 has the patch now.


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Andreas Hasenack-5
In reply to this post by Steve Langasek-6


On Tue, Dec 12, 2017 at 7:23 PM, Steve Langasek <[hidden email]> wrote:
On Tue, Dec 12, 2017 at 03:59:50PM +0000, Dimitri John Ledkov wrote:

> These are:
>  bind9

Fixed in Debian unstable; Server Team will merge it this cycle.



I also tested a build with openssl 1.1 from xnox's ppa and it worked fine.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Jeremy Bicha-2
In reply to this post by Steve Langasek-6
On Tue, Dec 12, 2017 at 4:23 PM, Steve Langasek
<[hidden email]> wrote:
>>  xchat-gnome
>
> Ubuntu-only package (dropped in Debian, dropped subsequently in Ubuntu, then
> brought back).  Did not ship in yakkety or zesty; when restored in artful it
> went straight to main because it was still seeded, but it's unclear this was
> ever reviewed by the Desktop Team or whether they want this package still in
> main.  (The re-uploader is not a member of the Desktop Team.)

xchat-gnome was demoted to universe this week.

Thanks,
Jeremy Bicha

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Dimitri John Ledkov
In reply to this post by Steve Langasek-6
On 12 December 2017 at 21:23, Steve Langasek <[hidden email]> wrote:

>
> On Tue, Dec 12, 2017 at 03:59:50PM +0000, Dimitri John Ledkov wrote:
> > openssl has changed api/abi. Currently Ubuntu ships 1.0.2 LTS series
> > openssl. Newer api/abi is available as a non-lts 1.1.0 series. Both
> > 1.0.2 and 1.1.0 series will go end of life upstream over the lifetime
> > of bionic.
> >
> > TLS 1.3 is currently undergoing standardisation
> > (https://github.com/tlswg/tls13-spec) But it seems like it is still
> > being actively iterated on.
> >
> > The next openssl series is expected to be 1.1.1 and it should be
> > binary compatible with 1.1.0 series. And 1.1.1 series are expected to
> > be released with TLS 1.3 support, after it is finalised and published.
> >
> > In Ubuntu, we would want to avoid shipping two openssl series
> > simultaneously. Or at least avoid having two series in main.
> >
> > I have rebuild openssl 1.1.0 package from debian, with modifications
> > to force provide all -dev packages pointint at 1.1.0 series, to
> > validate how many outstanding packages in main still do not support
> > 1.1.0 series api/abi in bionic in main.
> >
> > The failed build logs for main can be seen here:
> > https://launchpad.net/~xnox/+archive/ubuntu/openssl/+packages?field.name_filter=&field.status_filter=published&field.series_filter=bionic
> >
> > These are:
> >  bind9
>
> Fixed in Debian unstable; Server Team will merge it this cycle.
>

In progress

> >  freerdp
>
> Fix available upstream: https://github.com/FreeRDP/FreeRDP/issues/3098
>

To cherrypcik

> >  linux
> >  nagios-nrpe
>
> Looks like we have an Ubuntu delta for OpenSSL 1.0 compatibility which could
> be easily dropped
> (https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/1715167)
>

Easy to fix

> >  net-snmp
>
> Patch available in Debian BTS, was deferred for stretch:
> https://bugs.debian.org/828449
>

Fixed.

> >  openhpi
>
> Debian bug, no patch: https://bugs.debian.org/859543
>

Fixed.

> >  openssh
>
> As discussed.
>
> >  pam-p11
>
> Debian bug, no patch: https://bugs.debian.org/871939
> Upstream issue open: https://github.com/OpenSC/pam_p11/issues/6
>

Upload the fix to debian, will sync.

> >  ppp
>
> Ubuntu-specific build failure due to non-upstreamed eap-tls patch.  Patch
> author has new version of patch available at
> https://www.nikhef.nl/~janjust/ppp/download.html for OpenSSL 1.1.
>

Todo.

> >  qtbase-opensource-src

Todo, there is a patch available for OpenSSL 1.1 compat backport for
this series in Fedora I believe.

> >  ruby2.3

ruby2.5 is in universe, transition to do.

> >  wpa
>
> New version available in Debian unstable with support for openssl 1.1.
>

Fixed.

> >  wvstreams
>
> Debian bug, no patch: https://bugs.debian.org/859791
> Unclear where the current 4.6.1 release originated from, the packaging
> points to https://github.com/apenwarr/wvstreams for the upstream but this
> has 4.3 as the last upstream release in 2010 and no commits since 2010.
> wvstreams is in main for wvdial, seeded on the live image, a decision last
> reviewed in 2010
> (https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/400573).  This
> should probably be reviewed for 18.04.
>

Proposing to demote to universe.

With above all done, it is feasible to ship openssl1.1 and openssl1.0
in bionic. With openssh the last remaining package using openssl1.0 in
main.

TLS had one more last call for the next draft of TLS1.3 to be published.
https://www.ietf.org/mail-archive/web/tls/current/msg25263.html

OpenSSL published an update
https://www.openssl.org/blog/blog/2018/01/18/f2f-london/ which does
state that everyone should move to 1.1.0 and that next series will be
1.1.1 with TLS1.3 support and hence api/abi compatible with 1.1.0
series.

I would like to make a call for openssl1.1 inclusion in Bionic main.

Regards,

Dimitri.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Jeremy Bicha-2
On Mon, Jan 29, 2018 at 6:48 AM, Dimitri John Ledkov <[hidden email]> wrote:
>> >  freerdp
>>
>> Fix available upstream: https://github.com/FreeRDP/FreeRDP/issues/3098
>>
>
> To cherrypcik

freerdp is no longer in main. freerdp2 should work fine with openssl 1.1

Thanks,
Jeremy Bicha

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Andreas Hasenack-5
In reply to this post by Dimitri John Ledkov


On Mon, Jan 29, 2018 at 9:48 AM, Dimitri John Ledkov <[hidden email]> wrote:

> >  net-snmp
>
> Patch available in Debian BTS, was deferred for stretch:
> https://bugs.debian.org/828449
>

Fixed.


It's stuck in excuses due to a hilarious chain of dep8 failures: net-snmp -> 389-ds-base -> python-ldap -> freipa

freeipa (the last upload) is stuck becauase needs bind9 9.11, for which I have an MP up[1] and am trying to clarify the lwresd drop that Debian did.


 

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Christian Ehrhardt
On Mon, Jan 29, 2018 at 5:26 PM, Andreas Hasenack <[hidden email]> wrote:

>
>
> On Mon, Jan 29, 2018 at 9:48 AM, Dimitri John Ledkov <[hidden email]>
> wrote:
>>
>>
>> > >  net-snmp
>> >
>> > Patch available in Debian BTS, was deferred for stretch:
>> > https://bugs.debian.org/828449
>> >
>>
>> Fixed.
>>
>
> It's stuck in excuses due to a hilarious chain of dep8 failures: net-snmp ->
> 389-ds-base -> python-ldap -> freipa

389-ds-base I hit as well, FYI:
See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888745
And: https://code.launchpad.net/~paelzer/britney/hints-ubuntu-mask-389-ds-base/+merge/336779

>
> freeipa (the last upload) is stuck becauase needs bind9 9.11, for which I
> have an MP up[1] and am trying to clarify the lwresd drop that Debian did.
>
> 1.
> https://code.launchpad.net/~ahasenack/ubuntu/+source/bind9/+git/bind9/+merge/336719
>
>
>
> --
> ubuntu-devel mailing list
> [hidden email]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>



--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Andreas Hasenack-5


On Mon, Jan 29, 2018 at 2:31 PM, Christian Ehrhardt <[hidden email]> wrote:
On Mon, Jan 29, 2018 at 5:26 PM, Andreas Hasenack <[hidden email]> wrote:
>
>
> On Mon, Jan 29, 2018 at 9:48 AM, Dimitri John Ledkov <[hidden email]>
> wrote:
>>
>>
>> > >  net-snmp
>> >
>> > Patch available in Debian BTS, was deferred for stretch:
>> > https://bugs.debian.org/828449
>> >
>>
>> Fixed.
>>
>
> It's stuck in excuses due to a hilarious chain of dep8 failures: net-snmp ->
> 389-ds-base -> python-ldap -> freipa

389-ds-base I hit as well, FYI:
See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888745
And: https://code.launchpad.net/~paelzer/britney/hints-ubuntu-mask-389-ds-base/+merge/336779


It is fixed in the new package in proposed:
389-ds-base (1.3.7.8-2) unstable; urgency=medium

  * Fix autopkgtest to be robust in the face of changed iproute2 output.

 -- Timo Aaltonen <[hidden email]>  Wed, 20 Dec 2017 15:57:26 +0200

With this diff:

-IP=`ip route get 1.1.1.1 | awk '{print $NF; exit}'`
+IP=`ip route get 1.1.1.1 | sed -n -e's/.*src //; s/ .*//; p; q'`

The fixed 389-ds-base package is now stuck in proposed because of python-ldap, which won't migrate because of freeipa, which won't migrate because it needs the new bind9.
 

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Andreas Hasenack-5


On Mon, Jan 29, 2018 at 2:38 PM, Andreas Hasenack <[hidden email]> wrote:


On Mon, Jan 29, 2018 at 2:31 PM, Christian Ehrhardt <[hidden email]> wrote:
On Mon, Jan 29, 2018 at 5:26 PM, Andreas Hasenack <[hidden email]> wrote:
>
>
> On Mon, Jan 29, 2018 at 9:48 AM, Dimitri John Ledkov <[hidden email]>
> wrote:
>>
>>
>> > >  net-snmp
>> >
>> > Patch available in Debian BTS, was deferred for stretch:
>> > https://bugs.debian.org/828449
>> >
>>
>> Fixed.
>>
>
> It's stuck in excuses due to a hilarious chain of dep8 failures: net-snmp ->
> 389-ds-base -> python-ldap -> freipa

389-ds-base I hit as well, FYI:
See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888745
And: https://code.launchpad.net/~paelzer/britney/hints-ubuntu-mask-389-ds-base/+merge/336779


It is fixed in the new package in proposed:
389-ds-base (1.3.7.8-2) unstable; urgency=medium

  * Fix autopkgtest to be robust in the face of changed iproute2 output.

 -- Timo Aaltonen <[hidden email]>  Wed, 20 Dec 2017 15:57:26 +0200

With this diff:

-IP=`ip route get 1.1.1.1 | awk '{print $NF; exit}'`
+IP=`ip route get 1.1.1.1 | sed -n -e's/.*src //; s/ .*//; p; q'`

The fixed 389-ds-base package is now stuck in proposed because of python-ldap, which won't migrate because of freeipa, which won't migrate because it needs the new bind9.
 

net-snmp is green now, but blocked on another package: perl. Perl has a ton of dependencies and running tests. Has been in the queue for 17 days now and most arm64 tests are still in progress, so it will be a (long) while. There are some reds already too. Will whoever uploaded perl check those?

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Road to new openssl

Steve Langasek-6
On Tue, Jan 30, 2018 at 09:26:04AM -0200, Andreas Hasenack wrote:
> net-snmp is green now, but blocked on another package: perl. Perl has a ton
> of dependencies and running tests. Has been in the queue for 17 days now
> and most arm64 tests are still in progress, so it will be a (long) while.
> There are some reds already too. Will whoever uploaded perl check those?

I've worked through the failures so far; they were all either testbed
failures (nova errors on ppc64el, dns errors on armhf), flaky tests, or
legitimate failures that shouldn't be considered regressions.  We probably
need a mass-retry of at least the recent failures on armhf and ppc64el, but
for armhf we should either wait for the queue to drain all the way, or
someone needs to filter out tests that have already been re-queued to avoid
making the backlog worse with duplicates.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment