A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#401

Post by status_quo69 » Fri, Jan 17, 2020, 5:09 PM UTC

jmull wrote: post #262

It's easy to get any bug fix you want: pay for them. If you think loading your expectations on to an unpaid volunteer and then harassing them over it will work out, hopefully this moment is a good learning experience for you. (Unfortunately, I can see from reading the comments that not everyone is getting it.) Perhaps someone should create an OSS contributor agreement where contributors explicitly agree to work long…

I want to preface my comment with "I agree with you"

However, in this case patches and reproductions were submitted and rejected as "boring". Whether the author really meant to use the word "boring" is neither here nor there, the result was that the fix was ignored, even though that's how open source works!

I've watched from the sidelines with no skin in the game (I use Rocket) and my conclusion from all of this is that the maintainer should have created an actix committee or group of maintainers to help shield from the inevitable bugs and issues that crop up. If the OG author wanted to step back to take a break from all of this, then fine, the rest of the group can continue to churn and work.

The original article that called out the behavior also called out other incredibly popular crates, like reqwests, for their underlying HTTP stack, yet there's not a shitstorm about those libraries. The obvious difference that I can see is the maintainer response to said criticisms.

EDIT: I also want to make clear that I hated the comment about never writing rust again. I'm not condoning that behavior at all

Re: A Sad Day for Rust

#402

Post by iovrthoughtthis » Fri, Jan 17, 2020, 5:10 PM UTC

solipsism wrote: post #306

elefantastisch wrote: post #189

Earlier quoted context omitted.

Meta-comment: Thank you. Online discussion would be much more productive if everyone clearly laid out the principles on which their viewpoint was based. Fundamentally, there are only a few ways honest people can disagree: Different principles, different information, different interpretation, or just plain misunderstanding. (Meta-meta: This is the principle that I believe and based this comment on.) Much of what makes…

This is a bit Pollyanna. People aren't logic robots that start from first principles and then derive all knowledge from logical reasoning. People are emotional, irrational beings. Those of us who fancy ourselves rational are constantly involved in irrational motivated reasoning helping us maintain that desired worldview. Not to say we shouldn't try to live up to the ideal you set forth. We should do our best. But the…

I’m not so certain emotion and logic are so fundamentally separate you know.

Perhaps logic is just our way of explaining our otherwise unexplainable decision making systems.

Re: A Sad Day for Rust

#403

Post by UncleMeat » Fri, Jan 17, 2020, 5:11 PM UTC

jimbokun wrote: post #127

coleifer wrote: post #71

Earlier quoted context omitted.

How about instead of pushing the responsibility on someone else, you take responsibility for YOUR security-sensitive context and do the research before you start installing libraries?

Isn't that exactly what happened? This article is someone who did that research on multiple Rust HTTP clients and reported what they found: https://medium.com/@shnatsel/smoke-testing-rust-http-clients... Which I believe is what kicked off the events leading to Klabnik's blog post?

That’s fine. “Hey, this project has bugs maybe don’t use it” is fine.

Dog piles on Internet forums because the dev isn’t doing what you want isn’t fine.

Re: A Sad Day for Rust

#404

Post by lidHanteyk » Fri, Jan 17, 2020, 5:11 PM UTC

steveklabnik wrote: post #197

lidHanteyk wrote: post #169

Sorry to add yet another top-level thread, but my take on this is that, while it is correct that unsafe-blocks are a central and contributing factor to this incident, it is incorrect that languages doing what Rust does fundamentally need unsafe-blocks. As long as Rust both has such an easy way to circumvent the type system, and a desire to supplant C and C++ on the basis of code quality and safety, there will be read…

What is your alternate proposal?

The proposal that has the most concrete chance of succeeding is probably to formalize some of Miri's behaviors as auditors [0], explicit syntactic annotations which indicate a type/function's willingness to have its source code inspected and have facts proven about its behavior.

In terms of quality engineering, the "page of assembly" strategy is the one that I think has the most merit. Write out enough machine-level code to boot the machine and provide an environment for some higher-level language. This should take about a page. Rinse and repeat until the higher-level language is high-level enough for comfort. VPRI supposedly had made this technique work for them. This would cleave Rust into two or more languages, though, and I gather that a big selling point of the language is the ability to compromise and allow many different safety perspectives into a single codebase.

I'm not Miyazaki; I can't just tell you that unsafe-blocks were a mistake. But clearly and obviously, to anybody watching who has considered design and implementation of programming languages, they were a mistake. Further, they're the same mistake as Safe Haskell. We keep making this mistake, as a community of designers and theorists, and we need to do better.

[0] http://www.erights.org/elang/kernel/auditors/

Re: A Sad Day for Rust

#405

Post by Sharlin » Fri, Jan 17, 2020, 5:12 PM UTC

jakear wrote: post #357

dbcfd wrote: post #302

Earlier quoted context omitted.

> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…

Did the patches obviously maintain the exact same behavior? If so, why should the author care about them? If not, it’s not the author’s responsibility to ensure they’re correct patches, but it is the author’s responsibility to ensure their package is correct. If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well), they have no responsibili…

> If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well)

Oh my. This was not about code aesthetics or some purely philosophical problem. It was about experimentally found undefined behavior that opened potential security vulnerabilities in the wild. The ”well it works fine so it must be correct” mentality is exactly what led us to this situation where the vast majority of critical net infrastructure code is full of vulnerabilities, the very problem that Rust attempts to alleviate in the first place. The problem with the existence of malevolent actors is that it matters little if your program works correctly in all common cases. Someone out there is going to be actively looking for the uncommon case and their goals may not align with yours.

Re: A Sad Day for Rust

#406

Post by AlchemistCamp » Fri, Jan 17, 2020, 5:12 PM UTC

NewsAware wrote: post #361

aprdm wrote: post #337

Earlier quoted context omitted.

Where does it say he has to accept patches ? Couldn't they simply fork it instead of acting like entitled kids ?

Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep. Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Read…

I'm not sure the practice is that common when the maintainer works for one of the largest 5 software companies in the world and that company is using the code.

Re: A Sad Day for Rust

#407

Post by hjek » Fri, Jan 17, 2020, 5:13 PM UTC

Ygg2 wrote: post #342

ddevault wrote: post #83

Earlier quoted context omitted.

>the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care" Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in ma…

> They were hateful and virtrolous Who's they? Most of PR commenters were courteous. The last few were rude, but so was the fafhrd91. https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...

> Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?

Re: A Sad Day for Rust

#408

Post by steveklabnik » Fri, Jan 17, 2020, 5:13 PM UTC

quotemstr wrote: post #372

steveklabnik wrote: post #324

Earlier quoted context omitted.

If you are trying to get people to use your project, understanding how those people perceive your project is step 1.

Agreed. But how do we define "people"? Are your prospective users all hanging out on Reddit and Twitter? Or are these two communities, as I believe, vocal but unrepresentative slices of a much larger potential silent user base?

Totally, I think that sometimes, forks do make sense! Sometimes, you have to be aggressive, and people will find it justified. io.js is a great example of this happening and working.

Re: A Sad Day for Rust

#409

Post by lostmyoldone » Fri, Jan 17, 2020, 5:14 PM UTC

dbcfd wrote: post #302

ddevault wrote: post #38

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…

It's his project. If he wants to act in a way you call "childish" - not that I agree with the characterization - neither I, you, or anyone else has much of anything to complain about.

If he says it's production ready, I have to assume he thinks it is. If you don't think so, you don't use it.

Open source projects dependent on a single person goes away all the time. If you aren't prepared to maintain it yourself for your use, don't use it.

Honesty is something we should expect, as well as some amount of mutual respect.

It's abundantly clear that anyone expecting him to dance to their tune was clearly lacking in respect. If you do a patch that isn't accepted you haven't lost anything, and have no grounds to complain, unless possibly if you had a prior agreement between you about you making that particular patch.

Many maintainers are absolutely inhumanly awesome, but that doesn't give us the right to expect anything at all from those who is "only" giving us tons of more or less awesome code!

Re: A Sad Day for Rust

#410

Post by rectang » Fri, Jan 17, 2020, 5:14 PM UTC

amyjess wrote: post #237

TheRealDunkirk wrote: post #186

Earlier quoted context omitted.

> Why is the maintainer responsible for that? It just seems to me that there's a give-and-take to being the maintainer of a popular open source project. You get help on the project in the form of people contributing patches, right? Doesn't simple human curtesy and a modicum of wisdom suggest that you should explain your rationale in accepting or rejecting them, to manage expectations, so that it doesn't end up like t…

And this is why I honestly don't ever want to release an open-source project. At the very least, I'm not going to make it easy for people to contribute. I'll keep the git repo private, go without a ticketing system, and just post tarballs full of code on a self-hosted website (I guess like the NetHack team used to do before 3.6, but they had a ticketing system, and I wouldn't). Maybe I'll even use a non-free license…

> Maybe I'll even use a non-free license just to reinforce my "you take what you can get" policy.

Consider CC0 instead.

As a veteran open source contributor, I totally understand that dealing with open source communities has a huge cost to go with the huge benefit. Even just vetting patches can be a pain when you care about security and architecture and don't want to spend time endlessly explaining your choices.

CC0 allows you to provide maximum benefit should you opt out of "social coding". People can go ahead and fork your stuff, or just use bits and pieces, without needing to deal with licensing or crediting headaches. (Significant consumers still have to track provenance, though.)