From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 89C921384F2 for ; Wed, 16 Jan 2013 22:37:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 665E821C121; Wed, 16 Jan 2013 22:37:15 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4B47021C072 for ; Wed, 16 Jan 2013 22:37:14 +0000 (UTC) Received: from localhost (unknown [200.89.69.133]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id B265B33D841 for ; Wed, 16 Jan 2013 22:37:12 +0000 (UTC) Date: Wed, 16 Jan 2013 19:37:05 -0300 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild Message-ID: <20130116193705.02bcc009@gentoo.org> In-Reply-To: <50F72134.6090900@gentoo.org> References: <20130116124002.B9FA22171D@flycatcher.gentoo.org> <20130116170907.6ee31e7d@gentoo.org> <50F70FE8.6000507@gentoo.org> <20130116183110.403ea209@gentoo.org> <50F72134.6090900@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.14; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: dcfffe71-6a49-4f3c-a02b-0efb795b54fb X-Archives-Hash: 326a72840012aa1455f2ccc6d9e7966a On Wed, 16 Jan 2013 22:52:52 +0100 Luca Barbato wrote: > On 16/01/13 22:31, Alexis Ballier wrote: > > interesting, did they report it? OTOH, they switched _after_ the > > 2.0.5 release which happens to be the latest one. Since vlc is > > probably the ffmpeg/libav interface the most popular in the world > > (due to their windows and mac builds), I'd like to see an actual > > release with it and see if there is any regression before claiming > > they use libav. > > Reported, dismissed as bug on their side IIRC. Hard to blame anyone without more info nor a description of the problem, it can even be a too quick analysis before dismissing it. > >> gst-ffmpeg/gst-libav works only with libav as per upstream desire > >> (thus the rename) > > > > you mean use libav internally? because 'per upstream desire' > > gst-ffmpeg or gst-libav always only worked with the internal libs :) > > it also appears to build and work fine with ffmpeg-0.10 > > To be more clear, latest gst-libav release does not build with latest > ffmpeg release, same said for the gst-libav backport. meaning bug #447838 ??? are you kidding ? > > Speaking about bias, the maintainer happens to be part of libav core > > developers and was even part of what is known as the 'ffmpeg > > coup' :) > > Meanwhile I preferred let people pick their poison since it is easy to > switch from one to another, in retrospect would had been better if I > just removed ffmpeg from the tree from day 0. Fortunately we're not debian and do not like when people impose their choice on us. > > None of what you cited is a problem for a downstream distribution, > > except maybe vlc+rtmp which should be fixed regardless. > > > xbmc and mplayer did not build last time I tried. xbmc will be a > > pain because it uses some libavfilter features not in libav. > > mplayer2 works decently here. I didn't try to look at xbmc yet. mplayer2 is a good player but unfortunately for me it doesn't come with a mencoder2. Being the one that did most of the porting to the recent APIs of libav* for xbmc, I can assure you that any help is very welcome to have a sane support for libav. > > I don't want to verify this and will trust you there, but I still > > don't consider 8 months to be a correct delay for handling a > > published vulnerability, whatever its origin may be. > > Crashes are always bad, we fix a lot of them every day, we obviously > introduce few new since we aren't perfect, calling all of them > security problems is a tad extreme in my opinion. It's probably the fault of the current trend of tagging most of the crashes as sec. issues. The problem here is that a crash fix is almost invisible, while a CVE gets very high visibility, and leaving time to malicious people for reinventing an attack is bad. > The problem with the "published vulnerabilities" had been usually us > being prevented from accessing the example vectors, now the situation > is way better. This is news to me, but good it improved. [...] A.