511–520 of 913 posts
A bunch of people who make era-defining software for free. A labor of love. Another bunch of people who make era-defining software where they extract everything they can. From customers, transactionally. From the first bunch, pure extraction (slavery, anyone?).
> (slavery, anyone?) It’s hard to take any comment seriously that tries to use “slavery” for situations where nobody is forced to do anything for anyone.
Earlier quoted context omitted.
It's a good quality bug report. But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1] Pretty crazy that ffmpeg supports the codec in the first place, IMHO. I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't b…
I'm sure that a hacker wouldn't think of trying to use an obscure format... https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
> If you used the scan to pdf functionality of a [Xerox] like this a decade ago, your PDF likely had a JBIG2 stream in it.
> decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.
Your point is still taken, but just to clarify that these are different situations. JBIG2 is included for legacy. The Lucas art codec is included for... completion's sake(?)
Earlier quoted context omitted.
No, it is a request to fix it. How the maintainer feels about it is up to them.
A request to fix it would be privately telling the maintainers about the issue. Publicly releasing it is a demand.
Earlier quoted context omitted.
> ffmpeg owes me nothing. I haven't paid them a dime. That is true. At the same time Google also does not owe the ffmpeg devs anything either. It applies both ways. The whole "pay us or we won't fix this" makes no sense.
> Google also does not owe the ffmpeg devs anything either. Then they can stop reporting bugs with their assinine one size fits all "policy." It's unwelcome and unnecessary. > It applies both ways. The difference is I do not presume things upon the ffmpeg developers. I just use their software. > The whole "pay us or we won't fix this" makes no sense. Pay us or stop reporting obscure bugs in unused codecs found using…
Right, they should just post the 0days on their blog.
Earlier quoted context omitted.
You should honestly consider not responding if you are unaware of Project Zero.
TFA is about Project Zero getting uppity about an unexploitable non-issue in ffmpeg. Project Zero hasn't reported any vulnerabilities in any software I maintain. Lots of other security groups have, some well respected as well, but to my knowledge none of these "outside" reports were actual vulnerabilities when analyzed in context.
Earlier quoted context omitted.
From TFA: > The latest episode was sparked after a Google AI agent found an especially obscure bug in FFmpeg. How obscure? This “medium impact issue in ffmpeg,” which the FFmpeg developers did patch, is “an issue with decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.” This doesn't feel like a medium-severity bug, and I think "Perhaps reconsider the severity" is…
I think it’s exceedingly reasonable for a maintainer to dispute the severity of a vulnerability, and to ultimately decide the severity.
Earlier quoted context omitted.
There are alternatives such as gstreamer and proprietary options. I can’t give names, but can confirm at least two moderately sized startups that use gstreamer in their media pipeline instead of ffmpeg (and no, they don’t use gst-libav). One because they are a rust shop and gstreamer is slightly better supported in that realm (due to an official binding), the other because they do complex transformations with the sou…
There are certainly features and use cases where gstreamer is better fit than ffmpeg. My point was it would be hard to imagine eschewing ffmpeg completely , not that there is no value for other tools and ffmpeg is better at everything. It is so versatile and ubiquitous it is hard to not use it somewhere. In my experience there usually is always some scenarios in the stack where throwing in ffmpeg for a step is simple…
Earlier quoted context omitted.
I don’t know about ffmpeg, but plenty of OSS projects have outlined rules for who/when a project-wide/administrative decision can be made. It’s usually outlined in a CONTRIB or similar file.
Doubtful that's enough for a copyright grant. You'd need a signed CLA.
Earlier quoted context omitted.
And then the argument for refusing to just pay ffmpeg developers gets even more flimsy. The entire point here is to pay for the fixes/features you keep demanding, else the project is just going to do as it desires and ignore you. More and more OSS projects are getting to this point as large enterprises (especially in the SaaS/PaaS spheres) continue to take advantage of those projects and treat them like unpaid worker…
Not really. Their whole reason for not funding open source is it essentially funds their competitors who use the same projects. That's why they'd rather build a closed fork in-house than just hand money to ffmpeg. It's a dumb reason, especially when there are CVE bugs like this one, but that's how executives think.
But given its license, they’re going to have to reveal those changes anyways (since many of the most common codecs trigger the GPL over LGPL clause of the license) or rewrite a significant chunk of the library.
Earlier quoted context omitted.
> (slavery, anyone?) It’s hard to take any comment seriously that tries to use “slavery” for situations where nobody is forced to do anything for anyone.
[flagged]