On 30.07.2014 00:54, Russ Allbery wrote:
Andreas Cadhalpun <andreas.cadhal...@googlemail.com> writes:
I must have failed to make my point again. :(
As far as I know there are hundreds of security updates (for all packages
together) in the lifetime of a stable release. Compared to that 10 is not
large. And, as I already mentioned, I think that some of the FFmpeg
updates are minor enough to go through stable-updates.
It doesn't make a software less secure, if (even minor) security fixes get
backported even to old release branches, rather the contrary.
Well... backporting security fixes more of a bare minimum -- that's just
something that has to happen if we're going to support the software at
all, with a handful of exceptions where the software is, for one reason or
another, important enough that we're willing to release with it even
though security patches aren't backported properly and then terminate
support in the middle of our normal stable process.
So it's good that FFmpeg upstream does that backporting.
But software should also not pose a significant security load in the first
place. That quantity of security vulnerabilities tells me that something
is deeply wrong with FFmpeg as an upstream source base. That's a sign of
code with a bad smell.
In my opinion the large amount of security fixes is due to the fact that
FFmpeg is a large codebase and that most of the code has to deal with
untrusted data, a.k.a. multimedia files.
Now, that doesn't necessarily mean that it doesn't belong in Debian.
Sometimes we have to hold our nose and live with that, and it sounds like
libav isn't necessarily a lot better.
On the contrary I think that Libav is worse, as it doesn't even apply
all patches for security vulnerabilities fixed in FFmpeg that also
affect Libav. Just have a look at the security tracker of Libav[1].
But those are really painful
statistics that, to me at least, indicate the world is crying out for a
replacement code base that accomplishes the same goals but was written
with a higher level of quality in mind.
Obviously easier said than done, of course.
The time needed to do that would likely be spent a lot better with
trying to find and fix the remaining vulnerabilities in FFmpeg, because
any rewrite of such a large code base inevitably introduces it's own
security bugs.
Is upstream aware that this is a really bad track record and trying to do
something proactive to increase the quality of the code, like
comprehensive auditing, or proactive rewrites to use more secure coding
practices such as some of the work that the LibreSSL team has been doing?
On 30.07.2014 01:01, Russ Allbery wrote:
> Ah, I should have Googled my own question.
>
>
http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html
>
> Well, that's... better than nothing. It's certainly part of an
> overall strategy, although that number of issues still indicates to
> me that there are style and architecture issues here that could
> benefit from more proactive design work. I could be wrong, having
> not looked at the code personally -- maybe the problem space is just
> really hard. But that seems like quite a lot of errors.
You could also have asked FFmpeg upstream. (I've CCed Michael
Niedermayer now.)
I'm sympathetic to the concerns of the security team and the release team
about supporting two code bases with this much security activity in a
stable release. Maybe it's still the right thing to do, but that's a lot
of work for them.
Of course I'm also sympathetic with the concerns of the security and
release teams. But given that the alternatives are either to drop Libav,
which the Libav maintainers would probably be unhappy about, or not
having FFmpeg in the next stable release, which a lot of other people
would be unhappy about, having both in stable seems like the least bad
solution.
Best regards,
Andreas
1: https://security-tracker.debian.org/tracker/source-package/libav
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d83869.90...@googlemail.com
