←back to thread

1124 points CrankyBear | 5 comments | | HN request time: 0.328s | source
1. andriamanitra ◴[] No.45899577[source]
As much as I hate to be on Google's side I think they're doing a reasonable thing here. Valid bug reports are valuable contributions on their own, and disclosing security issues is standard practice. Not disclosing them doesn't help anyone. Security through obscurity is not security. If neither FFMPEG nor Google dedicate resources to fixing the issue in 90 days, making it public at least ensures that it gets visibility and thus has a higher chance to get fixed by a third party.

I'm sure Google could (and probably should) do even more to help, but FFMPEG directing social media rage at a company for contributing to their project is a bone-headed move. There are countless non-Google companies relying on FFMPEG that do much less for the project, and a shit show like this is certainly not going to encourage them to get involved.

replies(2): >>45899608 #>>45900012 #
2. mrkiouak ◴[] No.45899608[source]
As someone who worked as a software engineer at Google on a service that heavily depended on FFmpeg, its absurd that Google posts security bugs (which have the obvious potential outcome of driving more free work) vs just paying an engineer to fix the bug.

I promise they are spending more on extra compute for resiliency and redundancy for FFMPEG issues than it would cost for a single SWE to just write a fix and then shepherd through the FFmpeg approval process.

replies(2): >>45899659 #>>45901393 #
3. mrkiouak ◴[] No.45899659[source]
Bonus comment: I was present for conversations about how Google should just write an internal version because of all the stability issues, but that that work would never get prioritized or be considered valuable because it wouldn't get anyone promoted (to be fair, given how widely FFmpeg is used, it would have gotten an L4 or L5 promoted, but it would have been a near sisyphean task over years to get to the point where you could demostrate the ridiculously high XXm-XXXm returns that would come from just helping to improve FFmpeg).
4. krick ◴[] No.45900012[source]
That was exactly my thought. To be fair, I probably end up thinking that because this article is written is this trashy dumbass style, which portrays it as "Google bug reports vs. ffmpeg bug fixes", which is simply unfair: as you've said, a bug report is a contribution, not some kind of a demand. That being said, I kinda do understand if someone from ffmpeg said something snarky about that on Twitter, since surely if Google (of all things) as an organization sees it valuable to contribute by sending bug reports, it surely isn't less feasible (logistically or economically) for them to also work on a patch, than it is for random people within ffmpeg mailing list itself.
5. cyberrock ◴[] No.45901393[source]
As someone who was on a project that stalled for a year because our patchset wasn't accepted by a different open source project (not Linux either), I can tell you from experience that it's not as easy as folks here make it out to be. Some maintainers (and Googlers) really want you to study at their mountaintop monastery before your code is worthy, and scrutiny is even higher now due to AI, as we can see from the complaints about this bug report. Now, I've merged enough open source patches on my personal time to know that most projects aren't like that, but based on this interaction, I seriously wonder if Google's patch would've been accepted without incident.

Maybe AmaGoogSoft deserves this, but then what's the threshold? If I'm in charge of Zoom or Discord and one of my engineers finds a bug, should I let them report it and risk a public blow-up? Or does my company's revenue need to be below $1B? $100M? This just poisons the well for everyone.