Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Josselin Mouette j...@debian.org schrieb: Le jeudi 31 juillet 2014 à 22:19 +0200, Pau Garcia i Quiles a écrit : How is it better to have libav, which does a lot less security bugfixing, in? I'd rather have a library that fixes bugs than one that passes in order to look more secure. When in fact it's less. I have no informed opinion on whether ffmpeg or libav is better. On the security front, it looks indeed like ffmpeg is doing better but it is still hearsay. I think ffmpeg is doing better in terms of handling security issues; when I contacted Michael Niedermeyer in private we has always quick to reply, while libav-security@ seems understaffed: Several queries in the past needed additional poking, some were left unaddressed until today. Also, the Google fuzzer guys stated that more samples are unfixed in libav compared to ffmpeg. Cheers, Moritz -- 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/slrnlts9a1.2k3@inutil.org
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Charles Plessy writes (Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian): Le Thu, Jul 31, 2014 at 04:29:53PM -0700, Russ Allbery a écrit : Based purely on security evaluations by others that I was able to find on the web, FFmpeg appears to be better at the moment than libav on the security front (although libav appears to be trying to catch up). Hello everybody At that point, and given the impressive number of users who expressed interest for having FFmpeg in Debian (see http://bugs.debian.org/729203), I think that it would be fair to ask the libav maintainers to provide arguments on whether to distribute both libraries or make a choice, even if it is against their own interest since they may see their packages removed at the end. Otherwise we are in that kind of frequent Debianesque situation where the winning strategy is to stay silent as long as possible. CCing libav@packages.d.o. Ian. -- 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/21467.33652.506530.19...@chiark.greenend.org.uk
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Le jeudi 31 juillet 2014 à 22:19 +0200, Pau Garcia i Quiles a écrit : How is it better to have libav, which does a lot less security bugfixing, in? I'd rather have a library that fixes bugs than one that passes in order to look more secure. When in fact it's less. I have no informed opinion on whether ffmpeg or libav is better. On the security front, it looks indeed like ffmpeg is doing better but it is still hearsay. What I know, though, is that it is not realistic to maintain two such libraries in the course of a stable release. Said otherwise: if we have a consensus that ffmpeg is better, then let’s do the switch NOW. Not after the freeze. If it’s too late, libav will be the sole implementation in jessie, and the switch will have to be done for jessie+1. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1406925100.13071.33.ca...@kagura.malsain.org
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Le mercredi 30 juillet 2014 à 00:39 +0200, Andreas Cadhalpun a écrit : I must have failed to make my point again. :( No, you are the one who misunderstands the point. 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. No FFmpeg security update is “minor”. Almost each ffmpeg security bug is a code execution one. Almost each and every one of them is hard to backport. Those 10 security updates might represent more work than 100 *really* minor security updates. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1406836447.13071.3.ca...@kagura.malsain.org
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Thu, Jul 31, 2014 at 9:54 PM, Josselin Mouette j...@debian.org wrote: No FFmpeg security update is “minor”. Almost each ffmpeg security bug is a code execution one. Almost each and every one of them is hard to backport. Those 10 security updates might represent more work than 100 *really* minor security updates. How is it better to have libav, which does a lot less security bugfixing, in? I'd rather have a library that fixes bugs than one that passes in order to look more secure. When in fact it's less. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Le jeudi, 31 juillet 2014, 22.19:28 Pau Garcia i Quiles a écrit : How is it better to have libav, which does a lot less security bugfixing, in? Our security team has to prepare the libav updates over the lifetime of wheezy anyway. Introducing ffmpeg in jessie (with or without dropping libav) means (at least) duplicating that work. OdyX -- 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/5354151.iF7zqzrZRY@gyllingar
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Josselin, On 31.07.2014 21:54, Josselin Mouette wrote: Le mercredi 30 juillet 2014 à 00:39 +0200, Andreas Cadhalpun a écrit : I must have failed to make my point again. :( No, you are the one who misunderstands the point. Thanks for sharing your opinion. 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. No FFmpeg security update is “minor”. While it's hard to proof your statement, I agree that most of the FFmpeg security fixes should not be considered minor. Still not every FFmpeg update (note that the word 'security' is absent here) fixes a severe security issue. Some contain only regression fixes. For example in the 2.2 release series, only 2.2.4 fixed a CVE, the other four updates did not, so could have gone through stable-updates. Almost each ffmpeg security bug is a code execution one. Almost each and every one of them is hard to backport. When making such a statement it is very helpful to explain how you came to this conclusion. For example, the last security fix (CVE-2014-4609) could be trivially backported even to the 0.5 branch. (I did so myself.) Those 10 security updates might represent more work than 100 *really* minor security updates. Even if it required a lot of work to backport the security fixes, that work would be done by FFmpeg upstream anyway. The security team would at most have to review the changes. Best regards, Andreas -- 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/53daae09.3000...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Didier, On 31.07.2014 22:36, Didier 'OdyX' Raboud wrote: Le jeudi, 31 juillet 2014, 22.19:28 Pau Garcia i Quiles a écrit : How is it better to have libav, which does a lot less security bugfixing, in? Our security team has to prepare the libav updates over the lifetime of wheezy anyway. As far as I know, both the updates for Libav and FFmpeg are prepared by their respective upstreams, then integrated into the Debian packages by the respective maintainers and only then comes work for the security team in reviewing the patches and writing a DSA. Introducing ffmpeg in jessie (with or without dropping libav) means (at least) duplicating that work. Since all the updates for Libav are merged by FFmpeg, it's not really duplicated work. At least in theory only the additional fixes of FFmpeg would have to be reviewed additionally. Best regards, Andreas -- 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/53dab016.2020...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Pau Garcia i Quiles pgqui...@elpauer.org writes: On Thu, Jul 31, 2014 at 9:54 PM, Josselin Mouette j...@debian.org wrote: No FFmpeg security update is “minor”. Almost each ffmpeg security bug is a code execution one. Almost each and every one of them is hard to backport. Those 10 security updates might represent more work than 100 *really* minor security updates. How is it better to have libav, which does a lot less security bugfixing, in? It's not. However, what was proposed was having *both* of them, not dropping libav in favor of FFmpeg. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87tx5xrw0u@windlord.stanford.edu
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Fri, Aug 1, 2014 at 12:41 AM, Russ Allbery r...@debian.org wrote: How is it better to have libav, which does a lot less security bugfixing, in? It's not. However, what was proposed was having *both* of them, not dropping libav in favor of FFmpeg. So had the proposal been hey, let's replace libav with ffmpeg, would you vote yes ? Only one library to maintain and review, and it happens to have good upstream support And replacing libav with ffmpeg is easy and the ffmpeg maintainer is committed to help port reverse dependencies. Looks good to me. Maybe Andreas should have made a not-so-polite proposal? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Pau Garcia i Quiles pgqui...@elpauer.org writes: So had the proposal been hey, let's replace libav with ffmpeg, would you vote yes ? Only one library to maintain and review, and it happens to have good upstream support And replacing libav with ffmpeg is easy and the ffmpeg maintainer is committed to help port reverse dependencies. Looks good to me. Maybe Andreas should have made a not-so-polite proposal? I personally don't have enough information to know why libav was chosen instead of FFmpeg, and the discussion on debian-devel so far has mostly come from FFmpeg advocates. So there's probably another side to the story that hasn't been stated here yet. Based purely on security evaluations by others that I was able to find on the web, FFmpeg appears to be better at the moment than libav on the security front (although libav appears to be trying to catch up). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/877g2trtse@windlord.stanford.edu
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Le Thu, Jul 31, 2014 at 04:29:53PM -0700, Russ Allbery a écrit : Based purely on security evaluations by others that I was able to find on the web, FFmpeg appears to be better at the moment than libav on the security front (although libav appears to be trying to catch up). Hello everybody At that point, and given the impressive number of users who expressed interest for having FFmpeg in Debian (see http://bugs.debian.org/729203), I think that it would be fair to ask the libav maintainers to provide arguments on whether to distribute both libraries or make a choice, even if it is against their own interest since they may see their packages removed at the end. Otherwise we are in that kind of frequent Debianesque situation where the winning strategy is to stay silent as long as possible. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140731233851.gc28...@falafel.plessy.net
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Fri, Aug 1, 2014 at 1:29 AM, Russ Allbery r...@debian.org wrote: I personally don't have enough information to know why libav was chosen instead of FFmpeg, and the discussion on debian-devel so far has mostly come from FFmpeg advocates. So there's probably another side to the story that hasn't been stated here yet. libav was not chosen in Debian ffmpeg had a leadership crisis a few years ago: Michael Niedermaier (who has written here) was accused of dictatorial methods by some ffmpeg developers. I don't know if they were right or not in their complains and frankly, I don't care. Those guys tried a coup d'etat, stealing the domain, name, code repository, logo and everything and leaving Michael out. When Michael was able to recover control of some things, and get a new hosting, source repository, etc, they forked ffmpeg in libav. The libav guys knowingly tried and still try to break ffmpeg by using the same library names and for a long time, version numbers too. The Debian maintainer of ffmpeg at the time (Reinhard, who has written here too) was one of the guys who took the libav side instead of the ffmpeg side. He used the ffmpeg package names to provide libav, and actively blocked any effort that would lead to src:ffmpeg being actual ffmpeg.org. That's why we have libav now instead of ffmpeg. I'm all for forks but if you do a fork, at least you do it with ethics: different library names, sonames, etc. The libav developers have tried from minute zero to create a conflict. And what has been the outcome of that? A library which worse than ffmpeg in features, codec support, security, and essentially everything. As someone mentioned way back in the thread, the only people who seem to prefer libav over ffmpeg are the libav developers. I am not involved in libav or ffmpeg and if libav would be better technically, in security, etc, I would be all for libav, even with all the ill-intented methods they used. But it's not the case: they disrupt peaceful open source communities (see this discussion, it's not the first time in Debian and it has happened in other distributions too) with what goal?... forcing a worse library in technical regards? OMG. Pointless. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Fri, Aug 01, 2014 at 01:50:26AM +0200, Pau Garcia i Quiles wrote: I'm all for forks but if you do a fork, at least you do it with ethics: different library names, sonames, etc. I have nothing resembling an informed opinion on the libav vs. ffmpeg upstream conflict, but this is just wrong. There is *nothing* unethical about reusing the library names and sonames when forking. In fact, the right to continue using such interfaces when creating a fork is a very important principle. There may have been a dispute over a domain name, and over which of two upstream development communities is the rightful successor to the project. But the only party that owns the interface names in Debian is Debian itself. There are various /pragmatic/ reasons why we should care about how each name is being used in the wider community, but that does not mean that the side of the fork that keeps the domain name, that has a majority of mind share, or that wins out in the end should be regarded as having a morally superior claim *because* of this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Thu, 31 Jul 2014, Steve Langasek wrote: upstream conflict, but this is just wrong. There is *nothing* unethical about reusing the library names and sonames when forking. In fact, the Besides, when changing APIs and breaking interaction with other programs that rely on the original API. You are right when the fork is API compatible (like extension of a library that provides the same API plus something more), but *not* when changing the API. In this case, me too, would consider it *incorrect* (I don't want to use unethical as it is difficult to define). Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- 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/20140801010853.gp29...@auth.logic.tuwien.ac.at
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Aug 01, Russ Allbery r...@debian.org wrote: I personally don't have enough information to know why libav was chosen instead of FFmpeg, and the discussion on debian-devel so far has mostly come from FFmpeg advocates. So there's probably another side to the story that hasn't been stated here yet. Probably because there are no libav advocates other than the libav developers... -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Charles Plessy ple...@debian.org writes: Le Thu, Jul 31, 2014 at 04:29:53PM -0700, Russ Allbery a écrit : Based purely on security evaluations by others that I was able to find on the web, FFmpeg appears to be better at the moment than libav on the security front (although libav appears to be trying to catch up). Hello everybody At that point, and given the impressive number of users who expressed interest for having FFmpeg in Debian (see http://bugs.debian.org/729203), I think that it would be fair to ask the libav maintainers to provide arguments on whether to distribute both libraries or make a choice, even if it is against their own interest since they may see their packages removed at the end. Otherwise we are in that kind of frequent Debianesque situation where the winning strategy is to stay silent as long as possible. From what I have read about this situation now and in the past, I would recommend to bring this to the CTTE right away and ask them to decide whether the ffmpeg package in Debian should provide libav or ffmpeg. I think it is unlikely that discussion between the concerned parties will lead to a consensus, the jessie freeze is upcoming, and almost every recent CTTE decision took several months. In other words, time is running out, don't waste it with a pointless discussion on debian-devel. Best, Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- 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/8738dgdc68@vostro.rath.org
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
What we do to combat that is All patches going into FFmpeg are reviewed with security in mind The codebase was repeatledly tested with fuzzed files to uncover all kinds of anomalies, all such found anomalies where fixed. Also independant of googles fuzzing efforts, some of our users have done their own fuzzing. And during google code in several students have as well manually tried to find security issues. FFmpeg is regularly tested with static code analyzsers like coverity and most issues found get quickly fixed FFmpeg is tested regularly with runtime memory checkers like valgrind, address sanitizer and others and all reproduceable issues are fixed, iam not aware of any open and reproduceable one Almost all of the internal APIs used in FFmpeg are designed to be secure, always passing array sizes and checking them instead of assuming the caller knows they are large enough, exceptions to this are just the most speed critical parts. Codecs which are WIP and arent up to security standards can be and are marked as experimental and will not be selected during autodetection unless overriden by the user. Something else to add to this list is that ffmpeg has a far larger base of installed users bring the more eyes principle into play. I can't speak as to how many linux distros use which fork, though I believe the vast majority of all libav installs are debian and its derivatives. Ffmpeg, meanwhile, has a huge install base in the Windows and to a lessor degree Macintosh worlds as the backend to nearly every free video player or transcoder out there. Virtually no upstreams with a choice are adopting libav, and I expect the number of those supporting it to dwindle as it continues drift away from ffmeg. I don't see this as being much different from the imagemagik/graphicsmagic situation. Sorry if my message formatting is screwed up. I'm on windows and have no idea what I'm doing.
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Andreas Cadhalpun: So it's good that FFmpeg upstream does that backporting. As opposed to, for example, MySQL and Iceweasel, for which there is practically a blanket permission to upload new upstream releases unchecked into stable. (There appears to be one for Mediawiki and OpenJDK too, which do their security backporting themselves. This could apply to ffmpeg as well.) bye, //mirabilos -- 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/lran33$9ve$2...@ger.gmane.org
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Thorsten Glaser t...@debian.org writes: As opposed to, for example, MySQL and Iceweasel, for which there is practically a blanket permission to upload new upstream releases unchecked into stable. (There appears to be one for Mediawiki and OpenJDK too, which do their security backporting themselves. This could apply to ffmpeg as well.) Those are the ones I referenced where we're holding our nose and going with a much less than ideal security policy because we don't have another good option. Those aren't packages that we can realistically drop from the archive. The same may apply to FFmpeg as well, but it's not a happy situation to be in. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87oaw6j11y@windlord.stanford.edu
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-07-29 03:20, Marco d'Itri wrote: if they are not drop in replacements, and it would also be a pain if higher up packages link-in both ffmpeg libav and some clashing symbols are present... This is why the new ffmpeg will use different symbols. Again, read the first message. according to the first message, this is *not* true. the packages will have different libraries-names / sonames, but this does not mean that they don't have clashing symbols. if both library foo (/usr/lib/libfoo.so.3.21) and library bar (/usr/lib/i386-linux-gnu/libbar.so.4.1) export the symbol knarzifax, then how do you make sure that an application that is linked against both libraries for different functionality always chooses the korrect knarzifax? this becomes a real world issue, as soon as plugins are involved (which i find a common practice to access multimedia frameworks). application flurp has a both flurp-plugin-libav and flurp-plugin-ffmpeg installed. whichever plugin is loaded first, will pull in a library that shadows the symbol knarzifax for the *other* plugin. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJT10jZAAoJELZQGcR/ejb4o1AP/3aoHeFNZ3xcOLl/I0Y9g5Fp GsejeqWuE59CTtoo/1jp5byhueA5Uw9LpmFOmfKttKvqG3sEXhIkXBOA9wATXYS1 uDsblHzuhKhKagmkQ42N1Ql0h+d7vkZA8/duaAtcSb+8HOU/peMRUMQx/MQyxF4X z8hrmSHMpd9S2QTFJxjIfFa0kCQ9gtBv+p/2BSCRpLkxQBDyCoZeHwTmNQnpac4S xYT5Qzo2YW7U5JKXjllHoKcvdBJ1+gYJYfByBcn7ZmHVSv2Ittu9pl7kgH+S1KPk kdK9mopt3B0riCnIR+m3467TJ4U/F/UQ5VuZwENZ5GqivyiqvHHyyWnf3T2aa+rC hZM+k7mF06kQzOWcRi9F9Mqa/Tt0myZKYZVqpJY/y4U6LUYeSAcNmr6b0vzUkxh1 9YG3RwXMLNQZz565Dw7NoqO/7BKgoviSwSnd6OpHruGIYfScPQGkh0q9eU8v4q0U wazXWQ9ks1hHmp4Ea5QJuT+S/BQv3I5QEW0QYXn6flUkDeyj+T27djBisugive7g yGWEr4sVGczzwXjo1T5vgYxNGzvxPeBWGUzJqsRtxqVZKYYyMLYdzNA0TUP1B3vK rQQJXi7oXDTt/ta7yp09Pbp3ZHqxkJbjpLibgYoY9g9dIsEab25jahIK5xRBytz1 6BtDVvwo6srTgQEqOjzw =vaCN -END PGP SIGNATURE- -- 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/53d748dc.4010...@debian.org
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Andreas Cadhalpun wrote: According to the changelog[1], there have been 8 security updates for ffmpeg in squeeze. There would have been more but the code has evolved too much for it to be feasible to backport the patches. Not to mention that some bugs that are being fixed are, for example, for incomplete checks - checks that don't exist in the 0.5 branch. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/lr7jjb$np3$1...@ger.gmane.org
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Jul 29, \IOhannes m zmölnig (Debian/GNU)\ umlae...@debian.org wrote: This is why the new ffmpeg will use different symbols. Again, read the first message. according to the first message, this is *not* true. It is: - To avoid potential problems when a program is linked against FFmpeg libraries and other libraries, which in turn are linked against Libav, the symbol versions are changed to e.g. LIBAVCODEC_FFMPEG_55 instead of LIBAVCODEC_55. https://lists.debian.org/debian-devel/2014/07/msg01010.html -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Dimitri,
On 29.07.2014 03:12, Dimitri John Ledkov wrote:
I don't have an opinion about ffmpeg vs libav, apart from how hard the
soname transitions are, especially in ubuntu where we somehow ended up
with ex-multimedia packages around that either never were in debian,
or have been long removed from testing and/or unstable.
There are only 6 additional reverse-build-dependencies of src:libav in
utopic. Two build against lib*-ffmpeg-dev without further changes, one
needs a simple patch to use pkg-config, one needs a patch to adapt to
newer API (also needed for Libav 10), one is BD-uninstallable and one
fails for unrelated reasons, but its build-dependencies on libav*-dev
seem to be unnecessary anyway.
Per package list:
alsa-plugins-extra: OK
bombono-dvd: PATCH CodecID
dvdstyler: Unmet build dependencies: libwxsvg-dev (= 2:1.0.9)
gstreamer-vaapi: error: unsupported GStreamer API version 1.4
kffmpegthumbnailer: OK
libdlna: PATCH pkg-config
The patches are attached to this mail.
Thankfully, we
have worked to make sure libav is in universe only and thus is not a
security maintenance burden. Nonetheless, libav10 transition is still
not complete in utopic today.
Is bombono-dvd the last blocker?
I haven't checked, but now abi
compatible/incompatible the two stacks are? cause it would be a pain
if they are not drop in replacements, and it would also be a pain if
higher up packages link-in both ffmpeg libav and some clashing
symbols are present...
As Marco already wrote, FFmpeg is packaged to be ABI incompatible with
Libav, having different sonames and different symbol versions.
and people start requesting to have build
variants against both.
This could theoretically be done, but I don't think anyone wants to
maintain such a thing, especially because it would need two different
source packages, as the development packages of FFmpeg and Libav have to
conflict.
Has a rebuild of all deps been done? How many
build failures there are? (On both debian ubuntu, ideally) Is
hardening flags / toolchain enabled in both, or either of the two?
I did a rebuild of all the reverse-build-dependencies in sid and the
results can be found in my original mail.
For Ubuntu, see the beginning of this mail.
I'm not sure what you want to know about hardening.
The packages are otherwise unchanged, so use hardening flags if they
already do.
If that question was about FFmpeg/Libav, then yes, FFmpeg uses
--toolchain=hardened and Libav hardening flags.
Best regards,
Andreas
diff --git a/debian/patches/CodecID.patch b/debian/patches/CodecID.patch
new file mode 100644
index 000..e85d2da
--- /dev/null
+++ b/debian/patches/CodecID.patch
@@ -0,0 +1,51 @@
+Description: Rename CodecID to AVCodecID
+
+Author: Andreas Cadhalpun andreas.cadhal...@googlemail.com
+Last-Update: 2014-07-29
+
+--- bombono-dvd-1.2.2.orig/src/mgui/ffviewer.cpp
bombono-dvd-1.2.2/src/mgui/ffviewer.cpp
+@@ -62,7 +62,7 @@ C_LINKAGE_BEGIN
+
+ typedef struct AVCodecTag {
+ #if LIBAVFORMAT_VERSION_INT = AV_VERSION_INT(52,39,00)
+-enum CodecID id;
++enum AVCodecID id;
+ #else
+ int id;
+ #endif
+@@ -70,14 +70,14 @@ typedef struct AVCodecTag {
+ } AVCodecTag;
+
+ #if LIBAVFORMAT_VERSION_INT = AV_VERSION_INT(52,34,00)
+-static uint FFCodecID2Tag(CodecID codec_id)
++static uint FFCodecID2Tag(AVCodecID codec_id)
+ {
+ unsigned int ff_codec_get_tag(const AVCodecTag *tags, int id);
+ extern const AVCodecTag ff_codec_bmp_tags[];
+ return ff_codec_get_tag(ff_codec_bmp_tags, codec_id);
+ }
+ #else
+-static uint FFCodecID2Tag(CodecID codec_id)
++static uint FFCodecID2Tag(AVCodecID codec_id)
+ {
+ unsigned int codec_get_tag(const AVCodecTag *tags, int id);
+ extern const AVCodecTag codec_bmp_tags[];
+@@ -388,7 +388,7 @@ static unsigned char GetChar(uint tag, i
+ return (tagbit_begin) 0xFF;
+ }
+
+-static std::string CodecID2Str(CodecID codec_id)
++static std::string CodecID2Str(AVCodecID codec_id)
+ {
+ #ifdef _MSC_VER
+ std::string tag_str = boost::format(%1%) % codec_id % bf::stop;
+@@ -406,7 +406,7 @@ static std::string CodecID2Str(CodecID c
+
+ #else // CALC_FF_TAG
+
+-static std::string CodecID2Str(CodecID codec_id)
++static std::string CodecID2Str(AVCodecID codec_id)
+ {
+ return Int2Str(codec_id);
+ }
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..03ff5cf
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CodecID.patch
diff --git a/debian/control b/debian/control
index 4cd4492..a460e04 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Ubuntu MOTU Developers ubuntu-m...@lists.ubuntu.com
Uploaders: Alexis Saettler ale...@saettler.org
XSBC-Original-Maintainer: Alexis Saettler ale...@saettler.org
Homepage: http://libdlna.geexbox.org
-Build-Depends: debhelper (= 7.0.50), libavcodec-dev (= 4:0.6), libavformat-dev (= 4:0.7)
+Build-Depends: debhelper (= 7.0.50), libavcodec-dev (= 4:0.6), libavformat-dev (=
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Raphael, On 29.07.2014 09:47, Raphael Geissert wrote: Andreas Cadhalpun wrote: According to the changelog[1], there have been 8 security updates for ffmpeg in squeeze. There would have been more You're right, my calculation is slightly flawed. but the code has evolved too much for it to be feasible to backport the patches. That is likely true for some, but not for others. The real reason that there have not been more security updates for ffmpeg in squeeze is that since 0.5.6 this is actually Libav and Libav upstream stopped providing backports to 0.5 after 0.5.10 in February 2013 [1]. FFmpeg upstream released 0.5.14 in July 2014 [2] with some more fixes [3]. So had both been in squeeze, there would have been four more, i.e. 16 security updates. Not to mention that some bugs that are being fixed are, for example, for incomplete checks - checks that don't exist in the 0.5 branch. What do you mean here? If the affected code is not there, then that's nice, because a backport is not needed. Best regards, Andreas 1: https://www.libav.org/releases/ 2: https://www.ffmpeg.org/releases/ 3: https://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=refs/heads/release/0.5 -- 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/53d7cf25.3040...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, Jul 29, 2014 at 6:10 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: I don't have an opinion about ffmpeg vs libav, apart from how hard the soname transitions are, especially in ubuntu where we somehow ended up with ex-multimedia packages around that either never were in debian, or have been long removed from testing and/or unstable. There are only 6 additional reverse-build-dependencies of src:libav in utopic. Two build against lib*-ffmpeg-dev without further changes, one needs a simple patch to use pkg-config, one needs a patch to adapt to newer API (also needed for Libav 10), one is BD-uninstallable and one fails for unrelated reasons, but its build-dependencies on libav*-dev seem to be unnecessary anyway. Per package list: alsa-plugins-extra: OK bombono-dvd: PATCH CodecID dvdstyler: Unmet build dependencies: libwxsvg-dev (= 2:1.0.9) gstreamer-vaapi: error: unsupported GStreamer API version 1.4 kffmpegthumbnailer: OK libdlna: PATCH pkg-config In addition to this, I would like to note there is a lot of closed-source software which uses ffmpeg instead of libav. Not saying it doesn't exist but I don't know a single piece of closed-source software which has moved from ffmpeg to libav. I know, I know non DFSG-free software, we don't care. Well, I do. E. g. I'm having trouble with Qt right now because I'm using the commercial SDK which indirectly uses ffmpeg to provide some codecs on Linux. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tuesday 29 July 2014 18:43:17 Andreas Cadhalpun wrote: On 29.07.2014 09:47, Raphael Geissert wrote: Andreas Cadhalpun wrote: According to the changelog[1], there have been 8 security updates for ffmpeg in squeeze. There would have been more You're right, my calculation is slightly flawed. That was my point, so please don't use it as an argument. Not to mention that some bugs that are being fixed are, for example, for incomplete checks - checks that don't exist in the 0.5 branch. What do you mean here? If the affected code is not there, then that's nice, because a backport is not needed. Let me rephrase it: the fix is for an incomplete check, but in 0.5 the check is missing - while the rest of the code is there. Which is kinda... worse. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/38022338.xExGetmtcr@eee
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 29.07.2014 21:59, Raphael Geissert wrote: On Tuesday 29 July 2014 18:43:17 Andreas Cadhalpun wrote: On 29.07.2014 09:47, Raphael Geissert wrote: Andreas Cadhalpun wrote: According to the changelog[1], there have been 8 security updates for ffmpeg in squeeze. There would have been more You're right, my calculation is slightly flawed. That was my point, so please don't use it as an argument. Maybe I didn't make my point clear enough, for which the actual number of the security uploads is not important, only the order of magnitude. Given the amount of software in Debian and thus the amount of security fixes necessary for a stable release, I think that the additional stable-security uploads for FFmpeg in the order of 10 per release will be hardly noticeable. While I understand and agree with the general idea of reducing code duplication, I have a really hard time trying to understand why the security team has such a strong opposition to the idea of having both FFmpeg and Libav in Debian stable. One argument against code duplication is the risk that security issues get fixed in one, but not in the other. But in this particular case FFmpeg upstream merges all security fixes from Libav, so an FFmpeg package in a stable release won't have that problem. What is particularly hard for me to understand is why e.g. MySQL and MariaDB can be in testing at the same time without much resistance from the security team, but FFmpeg and Libav can apparently not. Not to mention that some bugs that are being fixed are, for example, for incomplete checks - checks that don't exist in the 0.5 branch. What do you mean here? If the affected code is not there, then that's nice, because a backport is not needed. Let me rephrase it: the fix is for an incomplete check, but in 0.5 the check is missing - while the rest of the code is there. Which is kinda... worse. Now I see, what you mean. Indeed that's worse, but if one notices something like that, then the whole check can be backported instead of the change in the check. Though it probably would have been better to backport already the incomplete check, when it was introduced in the development branch. Best regards, Andreas -- 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/53d80eda.8040...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Andreas Cadhalpun andreas.cadhal...@googlemail.com writes: Given the amount of software in Debian and thus the amount of security fixes necessary for a stable release, I think that the additional stable-security uploads for FFmpeg in the order of 10 per release will be hardly noticeable. Er, 8 security updates over the course of a stable release is already very high. Wouldn't adding another 10 make that the least secure source package in Debian? I believe that's worse than web browsers, which have a very large attack surface and huge numbers of active and well-funded attackers. And this is just for a multimedia library. I suppose it depends on how many of those could be grouped into one update, and each Iceweasel update usually has multiple fixed CVEs, so maybe this isn't an entirely fair comparison. But still, those are jaw-dropping numbers. While I understand and agree with the general idea of reducing code duplication, I have a really hard time trying to understand why the security team has such a strong opposition to the idea of having both FFmpeg and Libav in Debian stable. Because the sorts of numbers that you're talking about indicate that this code is a complete security disaster. What is particularly hard for me to understand is why e.g. MySQL and MariaDB can be in testing at the same time without much resistance from the security team, but FFmpeg and Libav can apparently not. MySQL is already a security update problem due to Oracle's very unhelpful attitude towards security patches. And we're still talking about rather fewer security vulnerabilities than this, I believe. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87ppgnhmym@windlord.stanford.edu
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Russ, On 29.07.2014 23:30, Russ Allbery wrote: Andreas Cadhalpun andreas.cadhal...@googlemail.com writes: Given the amount of software in Debian and thus the amount of security fixes necessary for a stable release, I think that the additional stable-security uploads for FFmpeg in the order of 10 per release will be hardly noticeable. Er, 8 security updates over the course of a stable release is already very high. Wouldn't adding another 10 make that the least secure source package in Debian? I believe that's worse than web browsers, which have a very large attack surface and huge numbers of active and well-funded attackers. And this is just for a multimedia library. 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. Webbrowsers tend to have a lot more security issues and e.g. for Firefox 15 security releases are planned in two years[2]. More importantly, Mozilla supports one release only for one year. That is much worse than the case of FFmpeg. As e.g. the chromium browser uses FFmpeg[3] it is also under the scrutiny of the very same attackers and security researchers as webbrowsers. I suppose it depends on how many of those could be grouped into one update, and each Iceweasel update usually has multiple fixed CVEs, so maybe this isn't an entirely fair comparison. But still, those are jaw-dropping numbers. For the numbers of CVEs fixed in each FFmpeg release, please have a look at their security webpage[4]. Note how many of them get backported to old releases and if one isn't, that's probably because the old release didn't contain the vulnerable code. While I understand and agree with the general idea of reducing code duplication, I have a really hard time trying to understand why the security team has such a strong opposition to the idea of having both FFmpeg and Libav in Debian stable. Because the sorts of numbers that you're talking about indicate that this code is a complete security disaster. Seen from a different point of view they show that the security support of FFmpeg is very good. What is particularly hard for me to understand is why e.g. MySQL and MariaDB can be in testing at the same time without much resistance from the security team, but FFmpeg and Libav can apparently not. MySQL is already a security update problem due to Oracle's very unhelpful attitude towards security patches. And we're still talking about rather fewer security vulnerabilities than this, I believe. So this gives me the impression that MySQL has a worse security support than FFmpeg, which doesn't really help to understand why the security team seems to be fine with having both forks of that in Debian testing. Best regards, Andreas 1: https://security-tracker.debian.org/tracker/source-package/libav 2: https://www.mozilla.org/en-US/firefox/organizations/faq/ 3: https://src.chromium.org/svn/trunk/deps/third_party/ffmpeg/README.chromium 4: https://ffmpeg.org/security.html -- 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/53d82293.7010...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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. 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. 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. 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. 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? 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. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87a97rhj3k@windlord.stanford.edu
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Russ Allbery r...@debian.org writes: 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? 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. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/874mxzhirj@windlord.stanford.edu
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Wed, Jul 30, 2014 at 02:12:25AM +0200, Andreas Cadhalpun wrote: 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.) Yes the problem space is hard ... The problem with multimedia in relation to security is that * There are hundreads of different formats, requireing alot of code to support them * The input files and streams can generally not be trusted, which makes most of the code security relevant and a potential target for an exploit * Many and especially the most important and efficient formats are very complex * The code must be very fast, users want to see their movies play in realtime not waiting for each frame to be decoded. And most of the code is speed relevant Above applies to any implementation, and constrains architecture options ... What we do to combat that is All patches going into FFmpeg are reviewed with security in mind The codebase was repeatledly tested with fuzzed files to uncover all kinds of anomalies, all such found anomalies where fixed. Also independant of googles fuzzing efforts, some of our users have done their own fuzzing. And during google code in several students have as well manually tried to find security issues. FFmpeg is regularly tested with static code analyzsers like coverity and most issues found get quickly fixed FFmpeg is tested regularly with runtime memory checkers like valgrind, address sanitizer and others and all reproduceable issues are fixed, iam not aware of any open and reproduceable one Almost all of the internal APIs used in FFmpeg are designed to be secure, always passing array sizes and checking them instead of assuming the caller knows they are large enough, exceptions to this are just the most speed critical
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Jul 28, 2014 at 03:39:29 +0200, Andreas Cadhalpun wrote: Hi Reinhard, On 28.07.2014 02:05, Reinhard Tartler wrote: On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: * Does it make sense for me to switch my package? The rule of thumb is, if your upstream uses FFmpeg for development you probably want to switch to using it, too. In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. I discussed this with Moritz in the ITP bug. Moritz ended this discussion [a], and as I wasn't convinced by his arguments, I continued my work. If in the end really only one copy is allowed in the next stable release, I think it should be FFmpeg. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the question above. It remains to be seen, what the release team prefers: frustrated users and developers or both forks in jessie. The release team is likely to let the people involved in multimedia foo fight it out among themselves and pick a winner. We're not going to ship both and hand that mess over to the security team. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Ciao, On Mon, Jul 28, 2014 at 9:44 AM, Julien Cristau jcris...@debian.org wrote: The release team is likely to let the people involved in multimedia foo fight it out among themselves and pick a winner. We're not going to ship both and hand that mess over to the security team. Personally I don't feel like dropping libav in favor of ffmpeg now at this stage. It's too late for Jessie. Rather I'd suggest to start reconsidering such switch for Jessie+1. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- 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/CAMHuwoz9xxOPmzprD=aa0xuZkk7Vj4puvJkKYa=9dkgu4jt...@mail.gmail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Jul 28, Alessio Treglia ales...@debian.org wrote: Personally I don't feel like dropping libav in favor of ffmpeg now at this stage. It's too late for Jessie. Except that, for a lot of the depending packages, there would be an immediate benefit in the number of bugs fixed. Personally I feel that we have inflicted libav on our users for way more time than it was sensible to do. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Julien, On 28.07.2014 10:44, Julien Cristau wrote: It remains to be seen, what the release team prefers: frustrated users and developers or both forks in jessie. The release team is likely to let the people involved in multimedia foo fight it out among themselves and pick a winner. I am not interested in a fight and would prefer it very much if this discussion remained purely technical. Having a fresh memory of the last fight that took place on debian-devel, I do not think that repeating a similar disaster is a good idea. We're not going to ship both and hand that mess over to the security team. Could you please explain what mess you are talking about? According to the changelog[1], there have been 8 security updates for ffmpeg in squeeze. Two of them (4:0.5.6-2 and 4:0.5.6-3) do not contain security related fixes, but rather fix build failures of the previous security upload, so they do not really count. That makes about 6 security fix uploads in about 3 years for squeeze, i.e. 1 upload per 6 month. If there were both forks in Jessie, this might double the number of uploads to 12 in 3 years, but probably some of them could also go through stable-updates instead of stable-security. Is that an unbearable burden? A lot of other software in Debian has already alternatives, like desktop environments, web browsers, text editors and even init systems. Why should this not be the case for a multimedia framework? There is also one particularly similar case, as in the packages are forks and require many security updates: MySQL and MariaDB are currently in Debian testing. Just for comparison, MySQL in squeeze had 3 uploads to stable-security and 3 to oldstable(-security) [2]. As I mentioned this particular example in my discussion with Moritz, he said that the security team will be working with the release team to sort this out for jessie[3]. Now, 5 months later, he seems to have changed his mind, as I am not aware of any such attempt, but instead Moritz seems to support both [4][5]. Thanks in advance for taking the time to answer these questions. Best regards, Andreas 1: http://metadata.ftp-master.debian.org/changelogs//main/f/ffmpeg/ffmpeg_0.5.10-1_changelog 2: http://metadata.ftp-master.debian.org/changelogs//main/m/mysql-5.1/mysql-5.1_5.1.73-1_changelog 3: https://bugs.debian.org/729203#435 4: https://bugs.debian.org/754940 5: https://bugs.debian.org/754941 -- 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/53d62f9a.7040...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Jul 28, 2014 at 12:12 PM, IOhannes m zmölnig (Debian/GNU) umlae...@debian.org wrote: Except that, for a lot of the depending packages, there would be an immediate benefit in the number of bugs fixed. at least in theory. Plus I would definitely appreciate to see some bug stats supporting such a theory. Cheers. (IOhannes et Multimedia guys, please let's keep debian-devel in the loop, I feel this is much more of general interest than a thing that needs to be addressed internally in pkg-multimedia) -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- 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/CAMHuwowu6VQ85Xr-8W0d4rMDHWqF=nfxounncundfpzkgof...@mail.gmail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 (resending, to keep debian-devel and the bug-report in the loop) personally i would welcome if both libav and ffmpeg could co-exist within Debian¹. as i see it, libav and ffmpeg have diverged, and as such i would like to have the choice which one to use. On 2014-07-28 11:55, Marco d'Itri wrote: On Jul 28, Alessio Treglia ales...@debian.org wrote: Personally I don't feel like dropping libav in favor of ffmpeg now at this stage. + 1 i don't think that dropping libav is appropriate at all. Except that, for a lot of the depending packages, there would be an immediate benefit in the number of bugs fixed. at least in theory. Personally I feel that we have inflicted libav on our users for way more time than it was sensible to do. i would appreciate it, if you (and anybody else) used a less flammable | touchy language. fgmadr IOhannes ¹ but then i'm not a member of the security team :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJT1jRXAAoJELZQGcR/ejb45GYP/2a06m3B6PRGyjV6oGS1xwDg 0if/Lssn500F8yjrYFKnexKGZg6xncKVKJ+NJncX3pIWMKu/fOXKJusC5Z5eMdvg Ecruo7sXBojUnUxtaibGExkjdCWHv4wC/xwx/gQVUg3ijQGr5CQgZKXRPzf6dAG5 Sc4KS7w1SBtgLWaKvsOVhljSB39lye1cUk8vgkPkvSytJPiFMo1QSCDlbNz5JGbf 4c8viga5W9KCH5zMLzZTRQOkiPQpZMPsd/l220YX6ADwlBhnG/yRFBx7SBOnVDYb BIWb4MFrsCikzC5gJrJZdVAkB96AWOWR6J8N0s8LI2Y1ZwOIM4nJB1FNeQvFRaJI xe5p3dTI5DS7Kvc6i4LjKcO5m1EdZXeS1vV/OMDrLtgpfDC7pfhn3lImaYMPGCpA 60GNGo/PnbUMWGT3Z5JCeX/Q59X53d8DrW7gTcrQoSr6y0DN8AFEpcuDCYbd2ubt /A+0MeocRPNKGiNB7lEfvpSD3x3e4pGlSFB1AMgnwCGmpXzHeA51LzbDJGtfdWon x8L7OD5QD/LwRqQtAncRpf9jB56oJvktmznluSuCcJeY9ADSYH2YDPC1g3CCnuKG SOJpSClZrPjlc2511emDcnOaMJhkyjeQ8R+I67+I05r0jBdk2FDnFASsNVVcRV5o lzO+UTdVUs0nWsiDa+CX =PGZV -END PGP SIGNATURE- -- 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/53d6345a.6050...@debian.org
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28.07.2014 13:24, Alessio Treglia wrote: On Mon, Jul 28, 2014 at 12:12 PM, IOhannes m zmölnig (Debian/GNU) umlae...@debian.org wrote: Except that, for a lot of the depending packages, there would be an immediate benefit in the number of bugs fixed. at least in theory. Plus I would definitely appreciate to see some bug stats supporting such a theory. My original mail mentioned some examples. Once FFmpeg is in the archive, each maintainer of a multimedia package could test build it against FFmpeg and see which, if any, of the bugs reported against said package vanish. Best regards, Andreas -- 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/53d64f90.1020...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. Michael Niedermayer from FFmpeg upstream volunteered to help with any future security issues in FFmpeg packages in debian [1]. However: The change in Debian-specific symbol versioning and sonames being done to ffmpeg so that it is co-installable with libav *is* a problem. It has to be done in coordination with the Canonical guys, so that both Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol versioning. Otherwise, the ffmpeg packages will be of very limited use (useless to run third-party binary-only games ;-p). I don't think coordination with Ubuntu will be a problem. In comment #7 in the corresponding bug at launchpad [2] Dimitri John Ledkov wrote that Ubuntu won't introduce FFmpeg on it's on, but instead: If you wish to see a supported ffmpeg stack in both Debian and Ubuntu, please become a developer and start maintaining it in Debian. Best regards, Andreas 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#528 2: https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1263278 -- 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/53d658ba.5090...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Jul 28, 2014 at 04:05:46PM +0200, Andreas Cadhalpun wrote: On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. Michael Niedermayer from FFmpeg upstream volunteered to help with any future security issues in FFmpeg packages in debian [1]. Yes, i do! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28 July 2014 15:05, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. Michael Niedermayer from FFmpeg upstream volunteered to help with any future security issues in FFmpeg packages in debian [1]. However: The change in Debian-specific symbol versioning and sonames being done to ffmpeg so that it is co-installable with libav *is* a problem. It has to be done in coordination with the Canonical guys, so that both Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol versioning. Otherwise, the ffmpeg packages will be of very limited use (useless to run third-party binary-only games ;-p). I don't think coordination with Ubuntu will be a problem. In comment #7 in the corresponding bug at launchpad [2] Dimitri John Ledkov wrote that Ubuntu won't introduce FFmpeg on it's on, but instead: If you wish to see a supported ffmpeg stack in both Debian and Ubuntu, please become a developer and start maintaining it in Debian. I don't have an opinion about ffmpeg vs libav, apart from how hard the soname transitions are, especially in ubuntu where we somehow ended up with ex-multimedia packages around that either never were in debian, or have been long removed from testing and/or unstable. Thankfully, we have worked to make sure libav is in universe only and thus is not a security maintenance burden. Nonetheless, libav10 transition is still not complete in utopic today. I haven't checked, but now abi compatible/incompatible the two stacks are? cause it would be a pain if they are not drop in replacements, and it would also be a pain if higher up packages link-in both ffmpeg libav and some clashing symbols are present... and people start requesting to have build variants against both. Has a rebuild of all deps been done? How many build failures there are? (On both debian ubuntu, ideally) Is hardening flags / toolchain enabled in both, or either of the two? -- Regards, Dimitri. -- 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/canbhluhhhjz7fk26we2qf1h2ss5ynfahwzqx8lfz7wbxsbk...@mail.gmail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Jul 29, Dimitri John Ledkov x...@debian.org wrote: security maintenance burden. Nonetheless, libav10 transition is still not complete in utopic today. I haven't checked, but now abi compatible/incompatible the two stacks are? cause it would be a pain They really are not, this was explained in detail in the first message. if they are not drop in replacements, and it would also be a pain if higher up packages link-in both ffmpeg libav and some clashing symbols are present... This is why the new ffmpeg will use different symbols. Again, read the first message. and people start requesting to have build variants against both. I don't think so. The harsh reality is that the only people who love libav are the libav maintainers, so I expect that once ffmpeg will be available most maintainers will just switch their packages to it. Has a rebuild of all deps been done? How many Yes, the data was in the first message. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Reinhard, On 28.07.2014 02:05, Reinhard Tartler wrote: On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: * Does it make sense for me to switch my package? The rule of thumb is, if your upstream uses FFmpeg for development you probably want to switch to using it, too. In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. I discussed this with Moritz in the ITP bug. Moritz ended this discussion [a], and as I wasn't convinced by his arguments, I continued my work. If in the end really only one copy is allowed in the next stable release, I think it should be FFmpeg. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the question above. It remains to be seen, what the release team prefers: frustrated users and developers or both forks in jessie. I think it would be best if ftp-master left the ffmpeg package in NEW until an answer to this problem has been found. I fail to see how this would help anyone, it only makes testing the package more difficult. Whether or not the package is acceptable for the next stable release is not to be decided by the ftp-masters, but rather by the release team. [1] https://lists.debian.org/debian-devel/2014/02/msg00668.html The FFmpeg version currently in NEW has been there for more than 2 months and is thus outdated. If you want to test the current packages, you can build them from the repository on Alioth [17] (e.g. using git-buildpackage). Furthermore, we'd like to move the FFmpeg packaging under the umbrella of the pkg-multimedia team, because this would facilitate future FFmpeg transitions. I am curious why this is your first email about this matter to pkg-multimedia, and why do you write this email only now? In the last discussion on debian-devel it was suggested to get the FFmpeg packages into experimental first [b], before further discussion, so I tried to achieve that. As the package has been in NEW for a rather long time and the freeze is getting closer, sending this mail now seemed appropriate. Moreover, I am curious why I haven't seen you working on libavcodec bugs in Debian before, It would be great if I could fix every bug in Debian, but unfortunately my time is limited. Therefore, when I encounter a problem that cannot immediately be fixed, I try to work around it. The workaround for practically all problems I had with the Libav packages in Debian could be solved by installing FFmpeg binaries from third parties. Therefore I finally decided to work on a more sustainable solution, i.e. a FFmpeg package in Debian. and why do you believe you can do a better job with the ffmpeg package currently on NEW? It is a lot more likely that I work on fixing a bug that affects me, if there is no easy workaround. Best regards, Andreas a: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#568 b: https://lists.debian.org/debian-devel/2014/02/msg00714.html -- 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/53d5a9d1@googlemail.com
