Most active commenters

    ←back to thread

    FFmpeg to Google: Fund us or stop sending bugs

    (thenewstack.io)
    1124 points CrankyBear | 15 comments | 11 Nov 25 18:32 UTC | HN request time: 0.883s | source | bottom
    Show context
    woodruffw ◴[11 Nov 25 19:16 UTC] No.45891521[source]▶
    I’m an open source maintainer, so I empathize with the sentiment that large companies appear to produce labor for unpaid maintainers by disclosing security issues. But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it, or would otherwise need to accept the reputational hit that comes with not triaging security reports. That’s sometimes perfectly fine (it’s okay for projects to decide that security isn’t a priority!), but you can’t have it both ways.
    replies(13): >>45891613 #>>45891749 #>>45891930 #>>45892032 #>>45892263 #>>45892941 #>>45892989 #>>45894805 #>>45896179 #>>45897077 #>>45897316 #>>45898926 #>>45900786 #
    Msurrow ◴[11 Nov 25 19:22 UTC] No.45891613[source]▶
    My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless of if the project had a chance to fix it.

    To me its okay to “demand” from a for profit company (eg google) to fix an issue fast. Because they have ressources. But to “demand” that an oss project fix something with a certain (possibly tight) timeframe.. well I’m sure you better than me, that that’s not who volunteering works

    replies(5): >>45891699 #>>45891755 #>>45891844 #>>45893088 #>>45898343 #
    vadansky ◴[11 Nov 25 19:28 UTC] No.45891699[source]▶
    On the other hand as an ffmpeg user do you care? Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it? I mean someone could already be using the vulnerability regardless of what Google does.
    replies(9): >>45891756 #>>45891762 #>>45891975 #>>45892022 #>>45892359 #>>45892632 #>>45893251 #>>45895054 #>>45900572 #
    1. nemothekid ◴[11 Nov 25 20:25 UTC] No.45892359[source]▶
    >Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it?

    Yes? It's in the license

    >NO WARRANTY

    >15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

    If I really care, I can submit a patch or pay someone to. The ffmpeg devs don't owe me anything.

    replies(3): >>45892821 #>>45893079 #>>45902705 #
    2. inkysigma ◴[11 Nov 25 21:04 UTC] No.45892821[source]▶
    Not being told the existence of bugs is different from having a warranty on software. How would you submit a patch on a bug you were not aware of?

    Google should provide a fix but it's been standard to disclose a bug after a fixed time because the lack of disclosure doesn't remove the existence of the bug. This might have to be rethought in the context of OSS bugs but an MIT license shouldn't mean other people can't disclose bugs in my project.

    replies(1): >>45894787 #
    3. janalsncm ◴[11 Nov 25 21:24 UTC] No.45893079[source]▶
    All the license means is that I can’t sue them. It doesn’t mean I have to like it.

    Just because software makes no guarantees about being safe doesn’t mean I want it to be unsafe.

    replies(2): >>45893221 #>>45897360 #
    4. gowld ◴[11 Nov 25 21:37 UTC] No.45893221[source]▶
    If the software makes no guarantees about being safe, then you should assume it is unsafe.
    replies(4): >>45893353 #>>45893809 #>>45894429 #>>45898155 #
    5. rmunn ◴[11 Nov 25 21:49 UTC] No.45893353{3}[source]▶
    Have you ever used a piece of software that DID make guarantees about being safe?

    Every software I've ever used had a "NO WARRANTY" clause of some kind in the license. Whether an open-source license or a EULA. Every single one. Except, perhaps, for public-domain software that explicitly had no license, but even "licenses" like CC0 explicitly include "Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work ..."

    replies(1): >>45894972 #
    6. janalsncm ◴[11 Nov 25 22:32 UTC] No.45893809{3}[source]▶
    Anyone who has seen how the software is sausaged knows that. Security flaws will happen, no matter what the lawyers put in the license.

    And still, we live in a society. We have to use software, bugs or not.

    7. HDThoreaun ◴[11 Nov 25 23:40 UTC] No.45894429{3}[source]▶
    not possible to guarantee safety
    8. dotancohen ◴[12 Nov 25 00:22 UTC] No.45894787[source]▶
    Google publicly disclosing the bug doesn't only let affected users know. It also lets attackers know how they can exploit the software.

    Holding public disclosure over the heads of maintainers if they don't act fast enough is damaging not only to the project, but to end users themselves also. There was no pressing need to publicly disclose this 25 year old bug.

    replies(2): >>45895354 #>>45895786 #
    9. ndriscoll ◴[12 Nov 25 00:42 UTC] No.45894972{4}[source]▶
    I don't know what our contract terms were for security issues, but I've certainly worked on a product where we had 5 figure penalties for any processing errors or any failures of our system to perform its actions by certain times of day. You can absolutely have these things in a contract if you pay for it, and mass market software that you pay for likely also has some implied merchantability depending on jurisdiction.

    But yes things you get for free have no guarantees and there should be no expectations put in the gift giver beyond not being actively intentionally malicious.

    replies(1): >>45895424 #
    10. tpmoney ◴[12 Nov 25 01:27 UTC] No.45895354{3}[source]▶
    How is having a disclosure policy so that you balance the tradeoffs between informing people and leaving a bug unreported "holding" anything over the heads of the maintainers? They could just file public bug reports from the beginning. There's no requirement that they file non-public reports first, and certainly not everyone who does file a bug report is going to do so privately. If this is such a minuscule bug, then whether it's public or not doesn't matter. And if it's not a minuscule bug, then certainly giving some private period, but then also making a public disclosure is the only responsible thing to do.
    11. rmunn ◴[12 Nov 25 01:40 UTC] No.45895424{5}[source]▶
    Point. As part of a negotiated contract, some companies might indeed put in guarantees of software quality; I've never worked in the nuclear industry or any other industries where that would be required, so my perspective was a little skewed. But all mass-distributed software I've ever seen or heard of, free or not, has that "no warranty" clause, and only individual contracts are exceptions.

    Also, "depending on jurisdiction" is a good point as well. I'd forgotten how often I've seen things like "Offer not valid in the state of Delaware/California/wherever" or "If you live in Tennessee, this part of the contract is preempted by state law". (All states here are pulled out of a hat and used for examples only, I'm not thinking of any real laws).

    12. saagarjha ◴[12 Nov 25 02:35 UTC] No.45895786{3}[source]▶
    Come on, we let this argument die a decade ago. Disclosure timelines that match what the software author wants is a courtesy, not a requirement.
    13. samus ◴[12 Nov 25 07:43 UTC] No.45897360[source]▶
    Sorry to put it this bluntly, but you are not going to get what you want unless you do it yourself or you can convince, pay, browbeat, or threaten somebody to provide it for you.
    14. pjc50 ◴[12 Nov 25 09:33 UTC] No.45898155{3}[source]▶
    OK, then you can't decode videos.
    15. soerxpso ◴[12 Nov 25 17:11 UTC] No.45902705[source]▶
    That license also doesn't give the ffmpeg devs the right to dictate which bugs you're allowed to find, disclose privately, or disclose publicly. The software is provided as-is, without warranty, and I can do what I want with it, including reporting bugs. The ffmpeg devs can simply not read the bug reports, if they hate bug reports so much.