821–830 of 913 posts
This is so basic it shouldn't even have to be said.
Earlier quoted context omitted.
I don't think you should try to invoke the idea of naivete when you fail to address the unhappy but perfectly simple reality that the ideal option doesn't exist, is a fantasy that isn't actually available, and among the available options, even though none are good, one is worse than another. "obscurity isn't security" is true enough, as far as it goes, but is just not that far. And "put the bugs that won't be fixed s…
The bug exists whether it's reported to the maintainers or not, so yeah, it's pretty naive.
This is true. Congratulations. Man we are all so smart for getting that right. How could anyone get something so obvious and simple wrong?
What you leave out is "in a vacuum" and "all else being equal".
We are not in a vacuum and all else is not equal, and there are more than those 2 factors alone that interact.
Earlier quoted context omitted.
> Telling everyone this project doesnt care about security Google did nothing like this. If people infer that a hypothetical project doesn't care about security because they didn't fix anything, then they're right. It's not google's fault they're factually bad at security. Making someone look bad is not always a bad action. Drawing attention to that decision by publicly reporting a bug is not a demand for what the de…
Bullshit. That is exactly what google is doing. Demands aren’t necessarily malicious, but they’re certainly annoying for the person being demanded.
Earlier quoted context omitted.
I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.
> I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you. That just means the script kiddies will have more trouble, while more scary actors like foreign intellegence agencies will have free reign.
Earlier quoted context omitted.
You're correct, but it's the social norms -- or at least, the norms as I perceive them -- that I am talking about here. If you find yourself with potentially serious security bugs in your repo, then the social norm should be for you to take ownership of that because, well, it's your repo. The socially unacceptable activity here should be treating security issues as an irritation, or a problem outside your control. If…
It seems to me that they are not treating the security issue as an irritation, but instead the manner at which it was presented to them that is the problem.
Earlier quoted context omitted.
> 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. So the premise here is that AWS should waste their own money maintaining an internal fork in order to try to make their competitors do the same thing? But then Google or Intel or someone just fixes it a bit later and…
It's the tragedy of the commons all over again. You can see it in action everywhere people or communities should cooperate for the common good but don’t. Because many either fear being taken advantage of or quietly try to exploit the situation for their own gain.
The first is that you have a shared finite resource, the classic example being a field for grazing which can only support so many cattle. Everyone then has the incentive to graze their cattle there and over-graze the field until it's a barren cloud of dust because you might as well get what you can before it's gone. But that doesn't apply to software because it's not a finite resource. "He who lights his taper at mine, receives light without darkening me."
The second is that you're trying to produce an infinite resource, and then everybody wants somebody else to do it. This is the one that nominally applies to software, but only if you weren't already doing it for yourself! If you can justify the effort based only on your own usage then you don't lose anything by letting everyone else use it, and moreover you have something to gain, both because it builds goodwill and encourages reciprocity, and because most software has a network effect so you're better off if other people are using the same version you are. It also makes it so the effort you have to justify is only making some incremental improvement(s) to existing code instead of having to start from scratch or perpetually pay the ongoing maintenance costs of a private fork.
This is especially true if your company's business involves interacting with anything that even vaguely resembles a consolidated market, e.g. if your business is selling or leasing any kind of hardware. Because then you're in "Commoditize Your Complement" territory where you want the software to be a zero-margin fungible commodity instead of a consolidated market and you'd otherwise have a proprietary software company like Microsoft or Oracle extracting fees from you or competing with your hardware offering for the customer's finite total spend.
Earlier quoted context omitted.
This has nothing to do with payment. Not deliberately infecting your users with vulnerabilities is simply the right thing to do. Giving something away for free doesn't absolve you of certain basic ethical responsibilities.
They're not deliberately infecting users with anything. There effectively saying "here's example code showing how to deal with these video formats. NOTE THAT THESE ARE EXAMPLES THAT I WROTE FOR FUN. THEY ARE NOT MEANT FOR SERIOUS USE AND MAY NOT HANDLE ALL CORNER CASES SAFELY. THIS SHOULD BE OBVIOUS SINCE WE HAVE NO COMMERCIAL RELATIONSHIP AND YOU'RE DOWNLOADING RANDOM CODE FROM SOMEONE YOU DON'T KNOW ON THE INTERNET…
If they wanted to market ffmpeg as a toy project only, not to be trusted, they could do that, but they are not doing that.
Earlier quoted context omitted.
No one said make it proprietary; there are other OSS licenses that would make ffmpeg non-viable for commercial usage.
You need a copyright grant to change the license in any way.
Earlier quoted context omitted.
I don’t understand how it helps the community to publicly release instructions for attacking people, unless you’re trying to incentivize a company to fix their crap. In this case, there is no company to incentivize, so just report it privately. You can say publicly that “there is an ABC class vulnerability in XYZ component” so that users are aware of the risk.
It’s OSS so somebody who cares will fix it, and if nobody cares then it doesn’t really matter. This also informs users that it’s not safe to use ffmpeg or software derived from it to open untrusted files, and perhaps most importantly releasing this tells the distro package maintainers to disable the particular codec when packaging.
Earlier quoted context omitted.
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 not only fix it, but validate the fix. It probably took more time to write up the complaint about the bugs than to implement the fix.
I’m not on the beck and call of Google’s robot. Maybe if it was an actual engineer from Google doing this they would have gotten a better response. Don’t expect people to treat AIs the same way we treat people. But if you send me an automated report and then tell me to jump I’m telling you to f*ck off.
What happens if I send you an automated report that tells you of a meaningful problem you didn't know about, and don't tell you to jump?