Re: [LEDE-DEV] Fading out PolarSSL

2017-01-06 Thread Ted Hess
On Tue, 2017-01-03 at 17:32 +0100, Steven Barth wrote:
> Hey everyone,
> 
> > 
> > Currently known remaining users of polarssl are:
> > 
> >  * bmx7
> >  * pianod
> >  * shadowsocks-libev-polarssl
> >  * shairport-sync-mini
> >  * shairport-sync-polarssl
> >  * transmission-cli-polarssl
> >  * transmission-daemon-polarssl
> >  * transmission-remote-polarssl
> >  * umurmur-polarssl
> > 
> > 
> > Please provide feedback on which approach you'd prefer and if you'd be
> > affected by the PolarSSL deprecation or not.
> I think for all but the first two from this list, there is a 
> non-polarssl version already packaged.
> Which would mainly leave bmx7 and pianod as main concerns. I think the 
> former used to work with cyassl
> at some point in time and the latter should work with gnutls. Both of 
> which we have, so it might just
> be a minor change to the packaging Makefiles.
> 
> So from my point of view dropping libpolarssl now (with a bit of upfront 
> notice to the maintainers)
> makes more sense than trying to drop a package later which is a bit of 
> unexpected and am not sure if
> it can be effectively announced in a service release and just delays the 
> inevitable.
> 
> 
> Cheers,
> 
> Steven
> 
> ___
> lede-adm mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm

Drop it now.

Speaking for pianod and shairport-sync... I have already updated pianod (which I
still develop) to use mbed TLS and I am currently working with the shairport-
sync developer to replace PolarSSL with mbed TLS this weekend.

/ted

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] Fading out PolarSSL

2017-01-03 Thread Daniel Engberg

Hi,

I'm in favor of dropping it, don't see anything good in keeping outdated 
and unsupported libraries.


As far as package status goes...

shadowsocks-libev --> https://github.com/openwrt/packages/pull/3729 + 
https://github.com/lede-project/source/pull/657
pianod + shairport-sync* --> 
https://github.com/openwrt/packages/issues/3733

transmission* --> https://github.com/openwrt/packages/issues/3731
umurmur --> doesn't compile, pr submitted upstream

Best regards,
Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] Fading out PolarSSL

2017-01-03 Thread Toke Høiland-Jørgensen
Jo-Philipp Wich  writes:

> Hi list,
>
> the mbed TLS project (formerly known as PolarSSL) declared the mbedTLS
> 1.3 branch (packaged as "libpolarssl" by LEDE) to be EOL with the end of
> the year 2016. [1]
>
> In order to avoid shipping an outdated and possibly vulnerable SSL
> library with the first LEDE release we begun migrating core package
> dependencies and default library choices to the "mbedtls" package which
> includes the most recent 2.4.0 release of mbedTLS.
>
> There has been an ongoing discussion in IRC on how to handle the
> remaining users of the legacy PolarSSL package and whether to ship this
> library with the initial release and remove it later or whether to drop
> it now in order to catch potential fallout early.
>
> Since we didn't want to single-handedly decide this issue in IRC I took
> the topic to the list now to facilitate wider feedback.
>
> Right now there are more or less two approaches proposed:
>
> a) Keep libpolarssl available for the initial 17.01.0 release and drop
>it with the first maintenance release 17.01.1 about 6-8 weeks later
>
> b) Drop libpolarssl now, even before branching and urge the feed package
>maintainers to migrate users of libpolarssl to the libmbedtls
>variant

I'd say drop it immediately unless there is a pressing reason not to
(i.e., an important package that can't be ported). Far better to deal
with the fallout during an RC phase than have a possible regression on a
point release six weeks from now. And we won't be doing anyone any
favours by shipping a known obsolete SSL library in the first release.

Dropping it also makes sure that we get a chance to weed out all
packages that are still inadvertently built against the old version
(libcurl depends on libpolarssl on my install from last night's nightly
build, for instance).

-Toke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


[LEDE-DEV] Fading out PolarSSL

2017-01-03 Thread Jo-Philipp Wich
Hi list,

the mbed TLS project (formerly known as PolarSSL) declared the mbedTLS
1.3 branch (packaged as "libpolarssl" by LEDE) to be EOL with the end of
the year 2016. [1]

In order to avoid shipping an outdated and possibly vulnerable SSL
library with the first LEDE release we begun migrating core package
dependencies and default library choices to the "mbedtls" package which
includes the most recent 2.4.0 release of mbedTLS.

There has been an ongoing discussion in IRC on how to handle the
remaining users of the legacy PolarSSL package and whether to ship this
library with the initial release and remove it later or whether to drop
it now in order to catch potential fallout early.

Since we didn't want to single-handedly decide this issue in IRC I took
the topic to the list now to facilitate wider feedback.

Right now there are more or less two approaches proposed:

a) Keep libpolarssl available for the initial 17.01.0 release and drop
   it with the first maintenance release 17.01.1 about 6-8 weeks later

b) Drop libpolarssl now, even before branching and urge the feed package
   maintainers to migrate users of libpolarssl to the libmbedtls variant

Currently known remaining users of polarssl are:

 * bmx7
 * pianod
 * shadowsocks-libev-polarssl
 * shairport-sync-mini
 * shairport-sync-polarssl
 * transmission-cli-polarssl
 * transmission-daemon-polarssl
 * transmission-remote-polarssl
 * umurmur-polarssl


Please provide feedback on which approach you'd prefer and if you'd be
affected by the PolarSSL deprecation or not.

Regards,
Jo


1: https://tls.mbed.org/tech-updates/releases/mbedtls-2.0.0-released

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev