Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Ivan Kalvachev writes: > I'm quite sure the Security team is full of capable people who can > handle one more package. One, no, this statement is not correct. Not because the security team is not capable -- they are very capable -- but because they are not *full*. You imply that the security team has tons of resources and time to spare. Let me assure you that this is far from the case. This isn't even the case for security teams consisting of full-time staff paid by commercial Linux distributions, let alone volunteers for the Debian project. Two, the security team has already said that FFmpeg is not just "one more package," and that no, they can't handle the substantial incremental load from adding FFmpeg without removing libav. You may not think that should be the case, but I'm afraid your opinion on the topic doesn't matter unless you're finding a way to either reduce that work or add more resources. > FFmpeg takes security seriously. I'm sure that it does. The problem, however, is that taking security seriously, while possibly necessary, is not sufficient. I'm glad that FFmpeg takes security seriously, but what FFmpeg needs is to *have fewer security bugs*. This isn't about anyone's good intentions. It's about the reality of past, very negative experience with FFmpeg's security track record. It's clear that efforts are underway to improve that, such as through the fuzz testing work that Google (among others) has been doing. That's great, but I'm sure you can also understand that the past track record has been sufficiently bad that everyone will continue to be leery for a while. To change that impression, FFmpeg is going to have to substantially improve on its past security track record and then *maintain* that new level of security for some period of time. Note that all of the above statements also apply to libav. As near as I can tell, this is not a distinguishing characteristic between the two projects. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
wm4 writes: > Russ Allbery wrote: >> Note that all of the above statements also apply to libav. As near as I >> can tell, this is not a distinguishing characteristic between the two >> projects. > And that's an argument against switching to FFmpeg exactly how? It's not. Nor was I trying to make one. This part of the thread was discussing introducing FFmpeg into Debian alongside libav. As I believe I mentioned previously, although the code base underlying both projects has a bad past security track record, currently FFmpeg appears to be doing somewhat better than libav. I believe a member of the security team made a similar observation. So, when picking one, the security argument seems to be at least partly in FFmpeg's favor. That was not my point; my point was that picking both of them is something that had already been discussed and rejected for what to me feel like sound reasons. Security of course isn't the only consideration when picking one of the two, and regardless I'm not the person who would be deciding anything. Mostly I'm speaking up because it felt like people were going down blind alleys arguing about things that aren't really at issue. Note that experimental doesn't receive security support. I may be missing something (and here it's ftp-master that is the relevant decision-making party), but I haven't seen any obvious reason why one shouldn't introduce FFmpeg packages into experimental, particularly if people feel like there's anything to be gained by seeing concrete packaging work, letting people more easily experiment with the packages, and so forth. Of course, that by itself doesn't imply anything about the broader question of replacing libav with FFmpeg or not. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Derek Buitenhuis writes: > On 8/16/2014 11:27 PM, wm4 wrote: >> That is very valuable advice. We'll get to work right away. > I've added it to my TODO: > * Don't write bugs. That's a really bad way of avoiding security bugs. I'm sure you know that and are just being flippant, but I have to say that, as an outsider to the project who would like to use the software but who cares a lot about not introducing security weaknesses, it's hard to shake the feeling that this dismissive attitude is part of the problem. There were earlier responses in the thread along the same lines, arguing that the nature of FFmpeg means it will just inevitably have a bunch of security bugs. This sort of learned helplessness is really off-putting. Thankfully, I get the impression from other research that I was doing that it's *not* typical of FFmpeg as a whole, and that you all are, in fact, doing exactly the sorts of things that I would recommend. So this is probably just one of those pointless Internet arguments where everyone says things more aggressively than they actually mean them, and much heat is created with little light. But, for the record, what I was actually getting at is that the way to avoid a bunch of security bugs is not to stop writing bugs, because no one is going to achieve that. It's to put in place supporting infrastructure that makes it easier to write secure code and harder to write code where bugs create security problems. Trying to be closer to perfect in the code you write is a horrible way to achieve security. It doesn't work. Adding surrounding protective structure to the code so that the bugs do not compromise security, and putting systems in place that let the computer do lots more security sanity checking for you, are how other projects with similar challenges have achieved considerable improvements in security bug rates. In case there's anyone reading this who doesn't have a feel for what this looks like, the process the LibreSSL project is going through (regardless of one's opinion on the desirability of an OpenSSL fork) is very interesting. I've personally learned quite a bit from it, have now introduced reallocarray in my own code, and am planning on introducing strtonum. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
