tpmoney

20 ms·

241.
by tpmoney 11mo ago
> In the end, a report saying "fix this within 90 days or this gets public" for small-ish bugs like this is a kind of demand. Do this or this gets out and you'll have to make an express release to fix it anyway. I think th
242.
by tpmoney 11mo ago
I think it’s a good example of why it makes no sense. People are saying they would rather a world where people unknowingly get heavy metal poisoning from apples at the free orchard rather than a world where people are informed that some of
243.
by tpmoney 11mo ago
Yes and if you look on ffmpeg’s site you’ll find a link where they promote hiring their devs independently as consultants for ffmpeg work. Note the names of those maintainers. Now go to fflabs.eu, observe that they are an ffmpeg consulting
244.
by tpmoney 11mo ago
> Absolutely, but should the patch be done asap at the cost of other maybe more important security patches? Maybe, maybe not. Not all bugs are security vulns, and not all security vulns are exploitable I fully agree which is why I really
245.
by tpmoney 11mo ago
I agree, it would suck if ffmpeg dropped support for niche codec altogether. But that's orthogonal to whether or not the bug reports should be made public. And realistically the only way distros (or anyone) can know if they should or n
246.
by tpmoney 11mo ago
> None of these apply to volunteer projects. How so? Volunteer projects have maintainers assigned to the project writing code. The "resources" to fix a bug promptly are simply choosing to allocate your developer resources to fi
247.
by tpmoney 11mo ago
> Responsible disclosure policies for contributor-driven projects can differ from commercial projects. The can , but there's not an obvious reason why they should . If anything, public disclosure timelines for commercial closed so
248.
by tpmoney 11mo ago
The clock is always ticking. You have no idea when you find a vulnerability who knows about it or how or whether it is currently being actively exploited. A choice to delay disclosure is a choice to take on the risk that the bug is being ac
249.
by tpmoney 11mo ago
According to the ffmpeg maintainer's own website (fflabs.eu) Google is spending plenty of dimes helping to fix issues in ffmpeg. Certainly they're spending enough dimes for the maintainers to proudly display Google's logo on
250.
by tpmoney 11mo ago
A bug is a bug, regardless of the intent of the insertion. You have no idea if this bug was or wasn't intentionally inserted. It's of course very likely that it wasn't, but you don't and can't know that, especially
251.
by tpmoney 11mo ago
It takes even more time to read and understand a patch. Not only to you have to do all of the work of reading and understanding the bug report for which the patch is relevant, but you now also have to read and understand the submitted code,
252.
by tpmoney 11mo ago
No, my stance is that it is reasonable for ffmpeg to ask for patches along with bug fixes and that is it simultaneously reasonable for Google to submit bug reports without those patches. Just like it would be reasonable for Google to ask fo
253.
by tpmoney 11mo ago
> Even if you use LLMs to generate bug reports, you should have a human vet and repro them as real and significant and ensure they are written up for humans accurately and concisely, including all information that would be pertinent to a
254.
by tpmoney 11mo ago
I mean if we’re going to do sloppy analogies, a bug report for open source software as widely used as ffmpeg is more like “I noticed the trees in the back corner of your free apple orchard are producing apples with trace amounts of heavy me
255.
by tpmoney 11mo ago
> would they stop to consider what happens if everybody does that? It’s almost almost like bitching about the “free labor” open source projects are getting from their users, especially when that labor is of good quality and comes from a
256.
by tpmoney 11mo ago
So when someone finds a bug in software, in your mind the only acceptable options are: 1) Fix it yourself 2) Sit on it silently until the maintainers finally get some time to fix it That seems crazy to me. For one, not everyone who discover
257.
by tpmoney 11mo ago
> someone who's contributed their time as a volunteer to an open source software project that we have come to rely on, now has some sort of an obligation to drop everything and do more unpaid work for a trillion dollar company If yo
258.
by tpmoney 11mo ago
They regularly submit code and they buy consulting from the ffmpeg maintainers according to the maintainer's own website. It seems to me like they're already funding fixes in ffmpeg, and really everyone is just mad that this parti
259.
by tpmoney 11mo ago
Hands on work like filing a detailed bug report with suspected line numbers, reproduction code and likely causes? Look, I get it. It would be nice if Google had filed a patch with the bug. But also not every bug report is going to get a pat
260.
by tpmoney 11mo ago
Right, but how is that a benefit here? The bug report was a valid report, ffmpeg is objectively better for it having been filed. Google contributes to ffmpeg on a regular basis according to the git history. They also buy consulting services
261.
by tpmoney 11mo ago
The bug exists whether or not google publishes a public bug report. They are no more making the project less secure than if some retro-game enthusiast had found the same bug and made a blog post about it.
262.
by tpmoney 11mo ago
If they contribute nothing back, what are all the `google.com` email addresses in the git history doing? If they contribute nothing back, why are they listed as a customer of `fflabs.eu` which is apparently a private consulting company for
263.
by tpmoney 11mo ago
> If they were a good company they would not only report bugs but also have had developers fix the bugs, but they are selfish and greedy, everyone knows that. Google has a pretty regular stream of commits in the ffmpeg git history, and i
264.
by tpmoney 11mo ago
According to https://xcancel.com/argvee/status/1986194861855478213#m , google is a customer of fflabs.eu ( https://fflabs.eu ) which is just such a "support contracts" arm. Certainly the fflabs.
265.
by tpmoney 11mo ago
Google contributes to ffmpeg on a fairly regular basis https://git.ffmpeg.org/gitweb/ffmpeg.git/search/HEAD?s=@goog... No it's not "unreasonable" to ask for patches along with bug fixes, but
266.
by tpmoney 11mo ago
To be clear, what does relicensing to AGPL do here? Does the AGPL include licensing terms that forbid filing bug reports without also including code patches? Or does it just make ffmpeg that much less appealing to projects and cut off the s
267.
by tpmoney 11mo ago
> They see the profit being made, and they're not even getting drops of it. Doesn't google routinely contribute to ffmpeg? Certainly there's a lot of commits from `@google.com` email addresses here: https://git.
268.
by tpmoney 11mo ago
If it takes 3 seconds to fix it, then how is this some massive burden on the maintainers? The bug report pointed to the relevant lines, the maintainers are the most familiar with the code and it probably would have taken them 1.5 seconds to
269.
by tpmoney 11mo ago
> In addition to your point, it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days. So when the xz backdoor was discovered, you think it would have been better to sit on that quietly and
270.
by tpmoney 11mo ago
Where in this bug report was there any expectation for a response? They filed a private bug report and have a policy of making private reports public in 90 days whether or not they get a response. How did the OSS world go from "with en

More ›