Re: Libavcodec being blacklisted with Firefox
Hi Jean-Yves Avenard,
2016-09-28 3:04 GMT+02:00 Jean-Yves Avenard <email@example.com>:
> On Tue, Sep 27, 2016 at 7:54 PM, James Cowgill <firstname.lastname@example.org> wrote:
>> > We discovered a serious security vulnerability in libavcodec 54 and
>> > earlier. Only libavcodec from LibAV is impacted.#
>> What is the security vulnerability you are referring to? Does it have a
>> CVE ID?
> I do not believe that it does... I will inquire about it.
Please do so. Many minor issues get CVE id and it would be surprising
if one with such big consequences would be left without an id.
Which commit fixed the issue?
>> > We have submitted fixes for libavcodec 54 to the LibAV team which have
>> > been accepted. They have also agreed to bump the micro version making the
>> > first version with no vulnerability version 54.35.1
>> > https://git.libav.org/?p=libav.git;a=shortlog;h=refs/heads/release/9
>> > libavcodec 53 is also impacted, however we have no solution for this.
>> This is a problem as Debian does not ship libavcodec 54. The versions
>> from version.h we currently have are:
>> Wheezy: libavcodec 53.35.0
>> Jessie: libavcodec 56.1.0 (not affected)
>> Stretch: libavcodec 57.48.101 (not affected, from ffmpeg)
>> > As a result, we have blacklisted libavcodec with a version earlier than
>> > 54.35.1.
>> We can't upgrade libavcodec 53 in Wheezy to libavcodec 54 because that
>> would break everything (ABI bump). Hypothetically, would it be possible
>> to allow a version like "53.35.1" which also fixes the vulnerability?
>> This would require some coordination with upstream.
Wheezy is handled by the LTS team (CC-d) and we are working with Diego
I guess bumping the version would be OK.
> libavcodec 53 is impacted in an entirely different manner than libavcodec
> 54. The fix for 54 was to backport key changes from 55. That approach will
> not work with 53.
> There's also the matter that none from LibAV was willing to help on the
> matter. They have stopped supporting 54 over 3 years ago and appeared very
> annoyed that it had been added to a LTS release. It came down to:" why
> should we help when no-one is willing to pay for our support"
> This is why we had to do the work ourselves for 54. They reluctantly
> accepted to merge our changes in their tree and made it clear that they
> would provide no support for it.
> I can only imagine that the situation for 53 will be even worse.
> Now, having said that, due to how 53 is failing for this particular issue, I
> believe the fix will likely be easier..
> The fact remain that libavcodec 53 is super old.
> How likely would user still on Wheezy be using it? I can imagine that on
> servers and so on
> So that beg the question.. does it matter? At a guess it's not impacting
> those users.
Libav is supported in Wheezy LTS and we plan fixing this vulnerability if
we get the details.