On Tue, Sep 13, 2016 at 05:47:12PM +0200, Markus Koschany wrote: > On 13.09.2016 16:48, Diego Biurrun wrote: > > On Tue, Sep 13, 2016 at 03:14:41PM +0200, Markus Koschany wrote: > [...] > >> In short we need: > >> > >> a) the single patches rebased against the current version in Wheezy or a > >> Git repository for the same purpose > > > > https://git.libav.org/?p=libav.git;a=shortlog;h=refs/heads/release/0.8 > > > >> b) a concrete statement what patches and how many should go into the > >> next security update > > > > All commits in the above branch, which will also appear in the next 0.8 > > release. > > When I click on the above link it is not clear to me which commit fixes > a specific CVE. If you click on the first commit listed there: https://git.libav.org/?p=libav.git;a=commit;h=281d22b18c2b4544c6f88e350f7404085a075d78 you should see the following log message: ac3_parser: add required padding for GetBitContext buffer Fixes stack buffer overflow errors detected by address sanitizer in various fate tests. Bug-Id: CVE-2016-7393 CC: libav-stable@libav.org (cherry picked from commit a9f108bd78e842a47ade2f7c8b22a1764d01d4e6) Signed-off-by: Diego Biurrun <diego@biurrun.de> The Bug-Id will always reference the CVE that I am fixing. > Just to understand what I'm aiming at, in Debian we use > quilt patches that are applied on top of the upstream release. We have a > clear distinction between upstream source and Debian specific changes. I > would prefer one patch per issue that corresponds to exactly one CVE or > clear instructions which commits fix which CVE. But I guess I will leave > this to Hugo now. There is no need for Debian-specific patches if I push everything upstream. Looks like a clear win-win situation to me. > >> c) a deadline > >> > >> Provided we can clarify a) and b) soon, would it be doable to release a > >> new security update at the end of September? > > > > The end of September sounds good to me, I can roll a new release then. > > Just to be clear a new upstream libav doesn't need to coincide with a > Debian security update. It wouldn't do any harm though. Important is > that we only fix security related issues and leave possible features out > that are not strictly needed to fix the CVEs. I think there is a misunderstanding here, so let me explain: 1) I've been using Debian for 15+ years now and I understand the policy for package updates that go into stable: only fixes for security and data loss or similarly catastrophic issues. 2) Libav has a similar policy for releases: no features, bug fixes only. 3) The 0.8 release was done on 2013-01-21 and it is not supported in any way any longer, the last point release was done 1.5 years ago. The only changes done to that branch are done by me. Nobody else touches it currently. Nor will anybody in the future, maintaining (what feels like) stone age releases is not what we consider a fun task. Summary: I believe we are completely on the same page here. The changes I am making to our 0.8 branch not only fit your criteria completely, they are done specifically for you. Doing my work upstream has the added benefit of avoiding distro-specific patches, which is always good. Also, there is the odd chance that a handful of other people or distros do use that old release still and will benefit from those bug fixes. Diego
Attachment:
signature.asc
Description: Digital signature