Josselin Mouette 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
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 opi
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
Charles Plessy 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
On Aug 01, Russ Allbery 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.
Proba
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.
Y
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.
On Fri, Aug 1, 2014 at 1:29 AM, Russ Allbery 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
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
Pau Garcia i Quiles 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
On Fri, Aug 1, 2014 at 12:41 AM, Russ Allbery 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
Pau Garcia i Quiles writes:
> On Thu, Jul 31, 2014 at 9:54 PM, Josselin Mouette 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 mor
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.
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 hund
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)
On Thu, Jul 31, 2014 at 9:54 PM, Josselin Mouette 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
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. Co
Thorsten Glaser 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. Thi
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
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 ha
On Wed, Jul 30, 2014 at 02:12:25AM +0200, Andreas Cadhalpun wrote:
> On 30.07.2014 00:54, Russ Allbery wrote:
> >Andreas Cadhalpun 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 lifeti
On 30.07.2014 00:54, Russ Allbery wrote:
Andreas Cadhalpun 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 mentione
Russ Allbery 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 ha
Andreas Cadhalpun 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
>
Hi Russ,
On 29.07.2014 23:30, Russ Allbery wrote:
Andreas Cadhalpun 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
Andreas Cadhalpun 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
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
Y
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 calculat
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
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 t
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
On Jul 29, "\"IOhannes m zmölnig (Debian/GNU)\"" 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 libr
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,
-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
On Jul 29, Dimitri John Ledkov 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
On 28 July 2014 15:05, 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
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
> >
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/testin
On 28.07.2014 13:24, Alessio Treglia wrote:
On Mon, Jul 28, 2014 at 12:12 PM, "IOhannes m zmölnig (Debian/GNU)"
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
-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
On Mon, Jul 28, 2014 at 12:12 PM, "IOhannes m zmölnig (Debian/GNU)"
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 t
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 n
On Jul 28, Alessio Treglia 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 inf
Ciao,
On Mon, Jul 28, 2014 at 9:44 AM, Julien Cristau 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 dro
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
> > wrote:
> >
> >> * Does it make sense for me to switch my package?
> >>The rule of thumb is, if your upstr
Hi Reinhard,
On 28.07.2014 02:05, Reinhard Tartler wrote:
On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun
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
46 matches
Mail list logo
