7 ms·
And enabled by default. That's the most mind-blowing bit of this feature. The backcompat argument is a deflection for shipping a time bomb into people's codeb
by x0x0 5y ago
And enabled by default. That's the most mind-blowing bit of this feature. The backcompat argument is a deflection for shipping a time bomb into people's codebases.
- closewith 5y agoTo be fair to the maintainers, they didn't ship anything into people's codebases. People chose Log4j and pulled it into their code. FOSS contributers aren't responsible for downstream use of their projects.
- watwut 5y agoI don't think this argument makes much sense, beyond completely legalistic. If you add backdoor to the used library, then yes you shipped it there. You don't have legal liability for consequences when it is found, but it does not make not being the one who shipped it. It just protects you legally, as it should.
- closewith 5y ago> I don't think this argument makes much sense, beyond completely legalistic. The downstream users chose to use Log4j, chose to upgrade to the version where the exploit was introduced, chose not to audit the code. It's their responsibility and theirs alone. A maintainer can release a new version of their software. No-one is under any obligation to use it. They certainly don't reach down into your repos and push their changes. So I agree that the maintainers shipped a release. I certainly don't agree that the shipped it into anyone else's codebase.
- watwut 5y ago> The downstream users chose to use Log4j, chose to upgrade to the version where the exploit was introduced, chose not to audit the code. It's their responsibility and theirs alone. No. It is manipulative framing where responsibility for backdoor is pushed onto users. It is especially ridiculous in the context of industry where not upgrading is seen as irresponsible. And especially ridiculous when the same industry pushes for open source and when companies eventually start to listen and use open source, acts like there was something wrong with using open source.
- jeltz 5y agoTotally agreed. If software is ever to become a serious and respected industry we can't just deny responsibility and blame the users as soon as something goes wrong.
- ta988 5y agoYou can already do like in real industries, pay someone to write you a logging framework and they will be responsible for it. Guess what, you can even pay someone to just be responsible and audit FOSS code for you. Looks like we are already a serious and respected industry that just contains a few complaining entitled users benefiting from the free work of others...
- PedroBatista 5y agoWhy don’t all those people affected by this ask for their money back?
- closewith 5y ago> No. It is manipulative framing where responsibility for backdoor is pushed onto users. I fundamentally disagree that anything was pushed onto downstream users. They explicitly pulled Log4j. Framing it as the maintainers pushing the update onto downstream users is itself so manipulative that I wonder if you are conversing in good faith. Framing the bug as a backdoor is absurdly manipulative. The Apache License even warns the users explicitly: > Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.
- watt 5y agoYou are the part of the problem then.
- gregoriol 5y agoMaintainers have responsibility over their code, not how it is integrated. Here the problem is entirely in their code, it is not depending on the downstream project or any way it is used there.
- seba_dos1 5y agoMaintainers have no responsibility at all, unless they're paid or bound by contracts in some other way. Some feel responsible regardless, but they certainly don't have to. They can even introduce vulnerabilities intentionally, and it's your responsibility if you trusted them not to.
- varajelle 5y ago> They can even introduce vulnerabilities intentionally, and it's your responsibility if you trusted them not to. Is that true? I can add code in my open source library to steal credit card numbers, and if you use it that'd be your fault?
- pjmlp 5y agoThere is a reason why some companies have internal repos only policy, and libraries only get added to them after legal and IT review.
- cutemonster 5y agoIt's not true. There's a legal system and they cannot do intentionally illegal things and fraud. But it's good to not trust random strangers at GitHub -- maybe a user profile is just a facade for a criminal gang, maybe untraceable so they can get away with it
- seba_dos1 5y agoNot every intentional vulnerability is meant for illegal things or fraud.
- gregoriol 5y ago
- x0x0 5y agoThey wrote code essentially willing to run exec on any string passed to it, enabled this feature by default, and then didn't loudly warn people that any string passed to log4j must be trusted. None of this is competent work.
- closewith 5y agoSurely then the responsibility lies with the people who decided to use this apparently incompetent work in their infrastructure? If I release terrible software with a license that expressly has no warranty and someone uses it, surely that's on them?
- x0x0 5y agoYou must audit every single line of code for every piece of software you use.
- tinus_hn 5y agoIt’s the equivalent of shipping a car with faulty brakes. It’s really debatable who is responsible.