Hacker News Reader

Comment by hypeatei | Hacker News Reader

You're not aware of the simplistic, single header C library culture that some developers like to partake in. Tsoding (a streamer) is a prime example of someone who likes developing/using these types of libraries. They acknowledge that these things aren't focused on "security" or "features" and that's okay. Not everything is a super serious business project exposed to thousands of paying customers.

View on HN

Hobby projects that prove useful have a tendency of starting to be used in production code, and then turning into CVEs down the road.

If there is a conscious intent of disregarding safety as you say, the Readme should have a prominent warning about that.

> Hobby projects that prove useful have a tendency of starting to be used in production code

Even if that is true, how is that the authors problem? The license clearly states that they're not responsible for damages. If you were developing such a serious project then you need the appropriate vetting process and/or support contracts for your dependencies.

I didn’t say it’s the author’s problem. It’s a problem with the code.

Why play all these semantic games? You're saying it's the author's problem. You want them to even edit their readme to include warnings for would be production/business users who don't want to pay for it.

GP is arguing about licences. Yes, formally there is no obligation, and I'm not saying the author has any such obligation.

In the present case, either the missing overflow check in the code is by mistake, and then it's warranted to point out the error, or, as I understood GGGP to be arguing, the author deliberately decided to neglect safety or correctness, and then in my opinion you can't reject the criticism as unwarranted if the project's presentation isn't explicit about that.

I'm not making anything the author's problem here. Rather, I'm defending my criticism of the code, and am giving arguments as to why it is generally good form to make it explicit if a project doesn't care about the code being safe and correct.

I understand your point and if I were the author I would want either a disclaimer or a fix. File an issue or make a pr. Filing an issue is quicker and more fruitful than dealing with folks here

It is useful to understand the limitations of such hobby programs to know what they are useful for.

then that is their problem, not the code author's. If you use a hobby project in production, that's on you

My personal take is: if the code is good enough, it should be trivial to switch to a better library at the point when needed.

> If there is a conscious intent of disregarding safety as you say, the Readme should have a prominent warning about that.

What do you consider this clause in the LICENSE:

>> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

A standard clause you can find in every open source license? It doesn't say anything about how serious the project takes security

You write only Rust code don't you?

I wish ;) You're talking about how Rust code usually uses the MIT license and this is a part of the MIT license?

Every open source license has a very similar clause, include but not limited to BSD, GPL, CDDL, MPL and Apache.

When such a library is used in production code, that's on the person who chose to use it in production, not on the original author of the library.

You are responsible for the code you ship, doesn't matter whether it's written by you, an LLM, or whether it's a third-party dependency.

While that is certainly true, we could also be nice and reduce the workload of someone reviewing their dependencies and write it down in the readme.

> They acknowledge that these things aren't focused on "security" or "features" and that's okay.

where? single header is just a way to package software, it has no relation to features, security or anything such...

Either you are :

- overestimating the gravity of a UB and its security implications

- underestimate the value of a 150 line json parser

- or overestimate the feasibility of having both a short and high quality parser.

It sometimes happens that fixing a bug is quicker than defending the low quality. Not everything is a tradeoff.

I have tsoding fatigue. Took a long time to get him out of the main page. I like the DIY attitude, but it gets old really fast.

https://news.ycombinator.com/item?id=44345740

No one cares. Stop complaining or GTFO.

Au contraire, I think people do care. Now I will continue complaining and raising awareness with renewed fervor.

So if its a hobby project designed for just a handful of people, its suddenly okay to endanger them due to being sloppy?

This is an open source project that you're not obligated to use nor did you pay for it. Who is it endangering?

The license also makes it clear that the authors aren't liable for any damages.

...and what open source software license in the world makes the author liable for damages?

Probably more of lack of explicit liability in the license.

every OSS license I've ever seen is "use at your own risk" essentially. That's how this whole system works.

You find a vulnerability? patch it, push change to repo maintainer.

https://xkcd.com/2347

Pretty sure the all caps text on the bottom of most open source licenses out there makes it clear

None. That is how RedHat makes money.

> The license also makes it clear that the authors aren't liable for any damages.

The license disclaims liability but that doesn't mean the author cannot ever be held liable. Ultimately, who is liable is up to a court to decide.

The code nor author don’t endanger anyone. Whoever uses it inappropriately endangers themselves or others.

Why are you using random, unvetted and unaudited code where safety is important?

Open Source is about sharing knowledge.

They are sharing their knowledge about how to create a tiny JSON parser. Where is the problem again?

Refer to the original comment. Seems like you are incapable of connecting the comment chain.

Have some manners please.

Yes, pretty much. It has enough of a warning.

Reply on news.ycombinator.com