Update from polarssl to mbed 1.3.11

This patch updates the polarssl package to build the current mbed 1.3.x
release.

It also prefixes the generated binaries with mbed_, to avoid names that
overlap with other packages (like sha1sum) or that are generic and
confusing (like selftest or hello).

Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
---
 package/polarssl/0001-no-test-suite.patch          | 27 ----------------------
 ...he-standard-CMake-flag-to-drive-the-share.patch | 18 +++++++--------
 package/polarssl/polarssl.hash                     |  4 ++--
 package/polarssl/polarssl.mk                       | 17 +++++++++++---
 4 files changed, 25 insertions(+), 41 deletions(-)
 delete mode 100644 package/polarssl/0001-no-test-suite.patch

On 16/07/15 17:58, Ed Swierk wrote:

> This patch updates the polarssl package to build the current mbed 1.3.x
> release.
>
> It also prefixes the generated binaries with mbed_, to avoid names that
> overlap with other packages (like sha1sum) or that are generic and
> confusing (like selftest or hello).

And breaks at least openvpn in the process since 1.2.x and 1.3.x are API 
incompatible (also Hiawatha but a bump would fix that).
I didn't test rtmpdump or shairport-sync for breakage.
So there's more to do than just bump (there's no openvpn release 
compatible with 1.3.x, that's scheduled for the 2.4.x branch).
Regards.

Dear Ed Swierk,

On Thu, 16 Jul 2015 13:58:49 -0700, Ed Swierk wrote:
> This patch updates the polarssl package to build the current mbed 1.3.x
> release.
> 
> It also prefixes the generated binaries with mbed_, to avoid names that
> overlap with other packages (like sha1sum) or that are generic and
> confusing (like selftest or hello).
> 
> Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
> ---
>  package/polarssl/0001-no-test-suite.patch          | 27 ----------------------
>  ...he-standard-CMake-flag-to-drive-the-share.patch | 18 +++++++--------
>  package/polarssl/polarssl.hash                     |  4 ++--
>  package/polarssl/polarssl.mk                       | 17 +++++++++++---
>  4 files changed, 25 insertions(+), 41 deletions(-)
>  delete mode 100644 package/polarssl/0001-no-test-suite.patch

Thanks for your patch. However, following Gustavo's comment, I've
marked your patch as "Changes Requested" in our patch tracking system.
Can you resubmit a new version that takes into account Gustavo's
comments?

Thanks!

Thomas

On 07/16/15 23:11, Thomas Petazzoni wrote:
> Dear Ed Swierk,
> 
> On Thu, 16 Jul 2015 13:58:49 -0700, Ed Swierk wrote:
>> This patch updates the polarssl package to build the current mbed 1.3.x
>> release.
>>
>> It also prefixes the generated binaries with mbed_, to avoid names that
>> overlap with other packages (like sha1sum) or that are generic and
>> confusing (like selftest or hello).
>>
>> Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
>> ---
>>  package/polarssl/0001-no-test-suite.patch          | 27 ----------------------
>>  ...he-standard-CMake-flag-to-drive-the-share.patch | 18 +++++++--------
>>  package/polarssl/polarssl.hash                     |  4 ++--
>>  package/polarssl/polarssl.mk                       | 17 +++++++++++---
>>  4 files changed, 25 insertions(+), 41 deletions(-)
>>  delete mode 100644 package/polarssl/0001-no-test-suite.patch
> 
> Thanks for your patch. However, following Gustavo's comment, I've
> marked your patch as "Changes Requested" in our patch tracking system.
> Can you resubmit a new version that takes into account Gustavo's
> comments?

 Since it anyway is not compatible and upstream changed name, perhaps it's
better just to create a new package called mbedtls? When we remove polarssl we
can make a legacy entry to point to mbedtls.

 Regards,
 Arnout

Arnout, Ed,

On Fri, 17 Jul 2015 00:32:59 +0200, Arnout Vandecappelle wrote:

> > Thanks for your patch. However, following Gustavo's comment, I've
> > marked your patch as "Changes Requested" in our patch tracking system.
> > Can you resubmit a new version that takes into account Gustavo's
> > comments?
> 
>  Since it anyway is not compatible and upstream changed name, perhaps it's
> better just to create a new package called mbedtls? When we remove polarssl we
> can make a legacy entry to point to mbedtls.

Why would we remove polarssl? Is the project dead? Or is mbedtls its
replacement?

Other than that, yes: if mbedtls is like a new library that is
incompatible with polarssl, then a separate package is the best option.

Thanks,

Thomas

On 17/07/15 04:52, Thomas Petazzoni wrote:

> Arnout, Ed,
>
> On Fri, 17 Jul 2015 00:32:59 +0200, Arnout Vandecappelle wrote:
>
>>> Thanks for your patch. However, following Gustavo's comment, I've
>>> marked your patch as "Changes Requested" in our patch tracking system.
>>> Can you resubmit a new version that takes into account Gustavo's
>>> comments?
>>
>>   Since it anyway is not compatible and upstream changed name, perhaps it's
>> better just to create a new package called mbedtls? When we remove polarssl we
>> can make a legacy entry to point to mbedtls.
>
> Why would we remove polarssl? Is the project dead? Or is mbedtls its
> replacement?
>
> Other than that, yes: if mbedtls is like a new library that is
> incompatible with polarssl, then a separate package is the best option.

mbedtls is polarssl, it just got renamed when they got bought by ARM.
Adding to confusion this was done with the 1.3+ branches but not with 
1.2 (which is in security maintenance).
It was to reflect that polarssl (now mbedtls) is the crypto library for 
the mbed operating system, even though it still works with linux (likely 
they enabled this with 1.3+ but never backported to 1.2- hence keeping 
the old name).
Last time i've checked the 1.2 and 1.3 series couldn't coexist sanely on 
the same system, and since programs checks for polarssl rather than 
mbedtls for now it's probably still the case.
rtmpdump can use any of the three optionally (gnutls, openssl, 
polarssl), dunno if it can handle 1.3+
curl needs 1.3+ (we never enabled polarssl support).
Newer hiawatha needs 1.3+ (or can use bundled).
shairport-sync can use either polarssl or openssl (mandatory one of 
them), dunno if it can handle 1.3+
openvpn can use openssl or polarssl (not 1.3+).
So it basically narrows down the choices, though it doesn't necessarily 
take down other packages.
Question is, keep 1.2 and some small targets small or go 1.3+ ?
Also there's mbedtls 2.0.0 now, which, again, breaks API. And this has a 
better chance of living side by side with polarssl 1.2 since they've 
renamed everything it seems.
Regards.

On 07/17/15 12:30, Gustavo Zacarias wrote:
> On 17/07/15 04:52, Thomas Petazzoni wrote:
> 
>> Arnout, Ed,
>>
>> On Fri, 17 Jul 2015 00:32:59 +0200, Arnout Vandecappelle wrote:
>>
>>>> Thanks for your patch. However, following Gustavo's comment, I've
>>>> marked your patch as "Changes Requested" in our patch tracking system.
>>>> Can you resubmit a new version that takes into account Gustavo's
>>>> comments?
>>>
>>>   Since it anyway is not compatible and upstream changed name, perhaps it's
>>> better just to create a new package called mbedtls? When we remove polarssl we
>>> can make a legacy entry to point to mbedtls.
>>
>> Why would we remove polarssl? Is the project dead? Or is mbedtls its
>> replacement?
>>
>> Other than that, yes: if mbedtls is like a new library that is
>> incompatible with polarssl, then a separate package is the best option.
> 
> mbedtls is polarssl, it just got renamed when they got bought by ARM.
> Adding to confusion this was done with the 1.3+ branches but not with 1.2 (which
> is in security maintenance).
> It was to reflect that polarssl (now mbedtls) is the crypto library for the mbed
> operating system, even though it still works with linux (likely they enabled
> this with 1.3+ but never backported to 1.2- hence keeping the old name).
> Last time i've checked the 1.2 and 1.3 series couldn't coexist sanely on the
> same system, and since programs checks for polarssl rather than mbedtls for now
> it's probably still the case.
> rtmpdump can use any of the three optionally (gnutls, openssl, polarssl), dunno
> if it can handle 1.3+
> curl needs 1.3+ (we never enabled polarssl support).
> Newer hiawatha needs 1.3+ (or can use bundled).
> shairport-sync can use either polarssl or openssl (mandatory one of them), dunno
> if it can handle 1.3+
> openvpn can use openssl or polarssl (not 1.3+).
> So it basically narrows down the choices, though it doesn't necessarily take
> down other packages.
> Question is, keep 1.2 and some small targets small or go 1.3+ ?
> Also there's mbedtls 2.0.0 now, which, again, breaks API. And this has a better
> chance of living side by side with polarssl 1.2 since they've renamed everything
> it seems.

 So the tarball called mbedtls installs a library called polarssl? Or does it
install a library called mbedtls with a symlink from polarssl?

 Either way, since there's an API change, I still think it makes sense to make
it a new package - that's what we do with webkitgtk24 as well. If side-by-side
is not possible, we can just make it depend on !polarssl or vice versa. It's a
bit of a pain while we have both polarssl and mbedtls because of the extra
select/depends stuff in the packages using it, but anyway most packages only
have automatic dependencies in the .mk file.

 With the API breakage in mbedtls 2.0 in mind, it's probably best to call the
new package mbedtls13 so we can eventually (when everything has migrated to 2.0
API) end up with just a single package mbedtls.

 All this for a TLS library that has simplicity as its USP :-)

 Regards,
 Arnout

On 17/07/15 08:11, Arnout Vandecappelle wrote:

>   So the tarball called mbedtls installs a library called polarssl? Or does it
> install a library called mbedtls with a symlink from polarssl?

The 1.3 series installs as polarssl for compatbility purposes.
I haven't looked at the 2.0 tarball but according to the release notes 
it should install as mbedtls since they broke API anyway (unless they're 
too shortsighted).

>   Either way, since there's an API change, I still think it makes sense to make
> it a new package - that's what we do with webkitgtk24 as well. If side-by-side
> is not possible, we can just make it depend on !polarssl or vice versa. It's a
> bit of a pain while we have both polarssl and mbedtls because of the extra
> select/depends stuff in the packages using it, but anyway most packages only
> have automatic dependencies in the .mk file.
>
>   With the API breakage in mbedtls 2.0 in mind, it's probably best to call the
> new package mbedtls13 so we can eventually (when everything has migrated to 2.0
> API) end up with just a single package mbedtls.

Question is, Ed, are you using mbedtls for your project?
Because that would make 2.0 more reasonable, in general we prefer the 
latest versions unless there's a special need in the form of BR packages 
that can't work with the latest version.
Regarding openvpn killing 1.2 would leave it in just-openssl ground, 
which isn't too ideal since openvpn+polarssl is probably smaller than 
openssl alone.
The openvpn 2.4 milestone/branch contains 1.3 support but it's no easy 
backport, in general we tend to avoid that and there's no release date 
set either. It also remains to be seen if that works with 2.0.

>   All this for a TLS library that has simplicity as its USP :-)

Heh, don't mention it, even openssl kept the API compatible (not ABI 
though, arguably that's it's main bloat problem).
Regards.