4 ms·

> But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things. Is that somehow _less_ of a terrible way to

by bigiain 11mo ago

> But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things. Is that somehow _less_ of a terrible way to think than "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"? > it really needs to be fixed in the up stream Lots of people love using "Free Software" that they didn't have to write as essential parts of their business. Way too many of them seem to blink right when they get to this bit of the licence they got it with: SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. (That's directly from Section 15 "NO WARRANTY of https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/release/4.0/COPYING.LGPLv2.1 https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/release/4.0... )

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 you could highlight the relevant part of the bug report that demanded the developers "drop everything" and do "unpaid work for a trillion dollar company", that would be great because I'm having trouble finding it. I see "hey, we found this bug, we found where we think the issue is in the code and here's a minimal reproduction. Also FYI we've sent you this bug report privately, but we will also be filing a public bug report after 90 days." And no, I don't think having a policy of doing a private bug report followed by a public report some time later qualifies as a demand. They could have just made a public report from the get go. They could also have made a private report and then surprised them with a public bug report some arbitrary amount of time later. Giving someone a private heads up before filing a public bug report is a courtesy, not a demand. And it's really funny to complain about Google expecting "unpaid work for a trillion dollar company", when the maintainers proudly proclaim that the likes of no less than Google ARE paying them for consulting work on ffmpeg[1][2][3] [1]: https://fflabs.eu https://fflabs.eu [2]: https://fflabs.eu/about/ https://fflabs.eu/about/ [3]: https://ffmpeg.org/consulting.html https://ffmpeg.org/consulting.html
- etiennebausson 11mo ago
  Publicly posting an exploitable bug IS asking for someone to drop everything and come fix the issue NOW.
  - 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 discovers a bug can fix it themselves. But also a patch doesn't fix it until it's merged. If filing a public bug report is expecting the maintainers to "drop everything and do free labor" then certainly dropping an unexpected PR with new code that makes heretofore unseen changes to a claimed security vulnerability must surely be a much stronger demand that the maintainers "drop everything" and do the "free labor" of validating the bug, validating the patch, merging the patch etc etc etc. So if the maintainers don't have time to patch a bug from a highly detailed bug report, they probably don't have time to review an unexpected patch for the same. So then what? Does people sit on that bug silently until someone finally gets around to having the time to review the PR. Or are they allowed to go public with the PR even though that's far more clearly a "demand to drop everything and come fix the issue NOW". I for one am quite happy the guy who found the XZ backdoor went public before a fix was in place. And if tomorrow someone discovers that all Debian 13 releases have a vulnerable SSH installation that allows root logins with the password `12345`, I frankly don't give a damn how overworked the SSH or Debian maintainers are, I want them to go public with that information too so the rest of us can shut off our Debian servers.
    - etiennebausson 11mo ago
      xz was a fundamentally different problem, it was code that had been maliciously introduced to a widespread library and the corrupted version was in the process of being deployed to multiple distributions. The clock was very much ticking.
      - tpmoney 11mo ago

by bigiain 11mo ago

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 you could highlight the relevant part of the bug report that demanded the developers "drop everything" and do "unpaid work for a trillion dollar company", that would be great because I'm having trouble finding it. I see "hey, we found this bug, we found where we think the issue is in the code and here's a minimal reproduction. Also FYI we've sent you this bug report privately, but we will also be filing a public bug report after 90 days." And no, I don't think having a policy of doing a private bug report followed by a public report some time later qualifies as a demand. They could have just made a public report from the get go. They could also have made a private report and then surprised them with a public bug report some arbitrary amount of time later. Giving someone a private heads up before filing a public bug report is a courtesy, not a demand. And it's really funny to complain about Google expecting "unpaid work for a trillion dollar company", when the maintainers proudly proclaim that the likes of no less than Google ARE paying them for consulting work on ffmpeg[1][2][3] [1]: https://fflabs.eu https://fflabs.eu [2]: https://fflabs.eu/about/ https://fflabs.eu/about/ [3]: https://ffmpeg.org/consulting.html https://ffmpeg.org/consulting.html

etiennebausson 11mo ago
Publicly posting an exploitable bug IS asking for someone to drop everything and come fix the issue NOW.
- 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 discovers a bug can fix it themselves. But also a patch doesn't fix it until it's merged. If filing a public bug report is expecting the maintainers to "drop everything and do free labor" then certainly dropping an unexpected PR with new code that makes heretofore unseen changes to a claimed security vulnerability must surely be a much stronger demand that the maintainers "drop everything" and do the "free labor" of validating the bug, validating the patch, merging the patch etc etc etc. So if the maintainers don't have time to patch a bug from a highly detailed bug report, they probably don't have time to review an unexpected patch for the same. So then what? Does people sit on that bug silently until someone finally gets around to having the time to review the PR. Or are they allowed to go public with the PR even though that's far more clearly a "demand to drop everything and come fix the issue NOW". I for one am quite happy the guy who found the XZ backdoor went public before a fix was in place. And if tomorrow someone discovers that all Debian 13 releases have a vulnerable SSH installation that allows root logins with the password `12345`, I frankly don't give a damn how overworked the SSH or Debian maintainers are, I want them to go public with that information too so the rest of us can shut off our Debian servers.
  - etiennebausson 11mo ago
    xz was a fundamentally different problem, it was code that had been maliciously introduced to a widespread library and the corrupted version was in the process of being deployed to multiple distributions. The clock was very much ticking.
    - tpmoney 11mo ago