News for hackers. Stuff that matters.
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by landmarker10 on Monday June 24, 2024 @06:51PM (#40781961)
So, where are the memory safety issues in the last decade for Postfix?

https://www.cvedetails.com/vulnerability-list/vendor_id-8450...

I see issues that could also occur in Rust. Should we rewrite (presumably plagiarize) Postfix in Rust?

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by jaas on Monday June 24, 2024 @07:16PM (#40782190)
People bring up postfix all the time in this context because supposedly nobody has ever found a memory safety vulnerability in it. Presumably this is supposed to make the point that it is possible to write complex programs in C safely.

The reason people know this about postfix and keep bringing this one specific example up is because it's so unusual! It's an example that almost stands alone, it's extraordinary.

I don't think this is making the point about the safety of C that you think it is.

There is a mountain of evidence suggesting that C is dangerous, particularly for network services, and one possible example to the contrary doesn't change that.

[dead]
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by maxbond on Monday June 24, 2024 @11:29PM (#40784154)
That's a bummer honestly, I would encourage you not to let Internet flamewars color your decisions about what languages you might learn. The well is seriously poisoned with regards to Rust in this community. That's more of a reflection on HN than the value of Rust as a technology or even the Rust community.

Don't learn Rust if you aren't interested, it's not a one true language, but don't cheat yourself on engaging with an interest because HN struggles to discuss it amicably.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by stouset on Tuesday June 25, 2024 @12:13PM (#40790322)
HN is capable of discussing it just fine. Low-effort, bad faith posts getting downvoted into oblivion is the system working as intended.

GP is obstinately failing to grasp the difference between “can” and “should”. Networked services can be securely written in C. Networked services should not be written in C.

There are people who can operate motor vehicles safely at speeds regularly in excess of 100mph. People should not do so on public roads.

[dead]
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by stouset on Monday June 24, 2024 @07:26PM (#40782282)
Downvoting isn’t censorship. It’s disagreement.

“What about this one C project that hasn’t been a mess of exploitable vulnerabilities” is thoroughly unconvincing in a world where networked C programs are an unending source of severe vulnerabilities.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by VancouverMan on Monday June 24, 2024 @08:08PM (#40782672)
When even a very small number of downvotes here can result in a comment's text being coloured in a way that makes it harder to read, or even nearly impossible to read in extreme cases, I think it's reasonable to equate downvoting with censorship.

Censorship doesn't require content to be completely hidden or blocked; even just partially obscuring the content in some way is still censorship.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by stouset on Monday June 24, 2024 @08:46PM (#40782985)
I disagree that this is equivalent to censorship, but it sure sounds like a really good incentive to make more convincing comments than “Then how do you explain this single counterexample? Checkmate, Rustaceans.”

Plenty of reasonable disagreement happens here without getting downvoted into obscurity. Substantive points are generally upvoted even when they’re controversial opinions. So I don’t feel too upset when borderline-trolling or bad-faith arguments get hidden by consensus.

Ironic counterexample: It looks like you may have gotten downvoted despite having a fundamentally reasonable perspective.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by kelnos on Monday June 24, 2024 @11:22PM (#40784103)
I wouldn't call it "censorship", but sure, let's say it is.

There's a reason why "this is the exception that proves the rule" is a common saying. Picking out one exceptional example of something, and using that to argue against a general point, is at best lazy, and at worst actively dishonest. I'm fine with those kinds of comments being "censored". They -- and the comments calling people out for doing this -- are boring and don't further discussion.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by kelnos on Monday June 24, 2024 @11:22PM (#40784104)
I wouldn't call it "censorship", but sure, let's say it is.

There's a reason why "this is the exception that proves the rule" is a common saying. Picking out one exceptional example of something, and using that to argue against a general point, is at best lazy, and at worst actively dishonest. I'm fine with those kinds of comments being "censored". They -- and their replies that call people out for doing this -- are boring and don't further discussion.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by devwastaken on Monday June 24, 2024 @07:10PM (#40782137)
It's not censorship to be downvoted for low quality posts. Please reference "intellectual honesty" and research how to have legitimate conversations. Reddit/Twitter/4chan esque communication is not appropriate for serious spaces.
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by lasjhdh on Monday June 24, 2024 @07:15PM (#40782183)
Intellectual honesty would be to point out the memory safety issue CVE of Postfix in the past decade. Which you studiously avoid. But in any Rust thread cult-like obedience without questioning is expected.
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by dmix on Monday June 24, 2024 @07:32PM (#40782340)
> Intellectual honesty would be to point out the memory safety issue CVE of Postfix in the past decade.

this thread isn't about Postfix, you brought up Postfix as a counterpoint to a wider topic where such a anecdote doesn't hold up nearly as well in a broader scope. Don't purposefully narrow the topic and move goalposts just to win internet fights.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by dequan on Monday June 24, 2024 @07:50PM (#40782518)
What an interesting coincidence that all three of these accounts were created within 15 minutes of each other. I'm sure all "three" users are being "intellectually honest" here.