Bug#803997: transition: polarssl
On 09/11/15 20:49, James Cowgill wrote:
> Hi,
>
> On Mon, 2015-11-09 at 19:19 +0100, Emilio Pozuelo Monfort wrote:
>> On 04/11/15 04:02, James Cowgill wrote:
>>> Package: release.debian.org
>>> User: release.debian.org@packages.debian.org
>>> Usertags: transition
>>> Severity: normal
>>> Forwarded: https://release.debian.org/transitions/html/auto-polarssl.html
>>> X-Debbugs-CC: polarssl@packages.debian.org
>>>
>>> Hi,
>>>
>>> polarssl needs a library transition. The name of the upstream project
>>> changed to 'mbedtls' so the SONAME has become 'libmbedtls9'. I've kept
>>> the name of the dev package as 'libpolarssl-dev' for the 1.3 series so
>>> every package doesn't need to be changed.
>>
>> Shouldn't there be a new libmbedtls-dev package, with libpolarssl-dev becoming a
>> transitional one?
>>
>> Shouldn't the source be renamed?
>
> Earlier this year (in 1.3.10) upstream renamed the project mbedTLS. In
> the 1.3 series they changed the soname, but not the API (ie all the
> headers, functions, etc are still called "polarssl").
>
> A few months later they released 2.0 which completely changed the API
> by renaming all the functions and doing various cleanups to the API
> which would brake many programs.
>
> The new 2.0 series is in NEW right now and called 'mbedtls' and
> contains a libmbedtls-dev package.
>
> I didn't want to rename the dev package since it would end up
> conflicting with the new 2.0 series and although the "brand" name is
> mbedTLS, it still follows polarssl's API.
Makes sense.
>>> The new version of polarssl fixes a grave security bug (#801413). I
>>> havn't got a response from the package maintainer at all in dealing
>>> with this so I NMUed the version currently in experimental.
>>
>> Doing this transition as a NMU seems a bit odd to me. Though hijacking the
>> package seems a bit premature since that bug was opened only a month ago.
>> If you renamed the source, then maybe you could get away with it :p
>
> Okay sorry I didn't mean to hijack anyone's package, I was just trying
> to fix this security bug affecting one of my packages and nothing
> seemed to be happening on it. Although my upload of mbedtls 2 does now
> feel like a bit of a hijack :/
No problem. Such a security sensitive package should be well maintained, by
someone who has the time to take care of security uploads to (old)stable. So I'd
say go ahead with that, and if the previous maintainer wants to help, then
that's great.
> Thinking about this, I could probably avoid this transition by waiting
> for mbedtls to pass NEW, porting all the rdeps, and then having
> polarssl removed from the archive. This would be the "end" goal anyway.
I'd prefer that. We can let polarssl get auto-removed from testing (or I may
just remove it together with the rdeps). As for stable, if the package is FUBAR
then you can request a removal from there in a separate bug.
> This transition is effectively a temporary fix since I don't know how
> long that will take, and in the mean time there will be a grave
> security bug affecting polarssl.
>
> If you're wondering why a transition has to happen to fix this bug at
> all, upstream basically said "do not try to backport any of these
> commits" when I asked them about the security bug (see some of the
> links in #801413).
Ack.
Cheers,
Emilio
Reply to: