Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Significant raise of reports

lwn.net

Post reply on HN
Print view View original

31–40 of 164 posts

Re: Significant raise of reports

#31

Post by armchairhacker »

dspillett wrote: post #15
psyklic wrote: post #10

Earlier quoted context omitted.

> Was software made before 2000 better? At the time of release, yes. They had to ensure the software worked before printing CDs and floppies. Nowadays they release buggy versions that users essentially test for them.

Also in terms of security, there was generally a much smaller potential attack surface and those surfaces were harder to reach because we were much less constantly connected.

I remember opening a webpage and being hacked seemed more likely. Adobe Flash and Java had more vulnerabilities and weaker (if any) sandboxes than JavaScript.

Re: Significant raise of reports

#32

Post by kibwen »

noosphr wrote: post #25
Sharlin wrote: post #9

Earlier quoted context omitted.

Around 70% of security vulnerabilities are about memory safety and only exist because software is written in C and C++. Because most vulnerabilities are in newly written code, Google has found that simply starting writing new code in Rust (rather than trying to rewrite existing codebases) quickly brings the number of found vulnerabilities down drastically.

And to a good approximation all real world Rust uses unsafe everywhere. So we now have a new code base in an undefined language which still has memory bugs. This is progress.

No, this is false. For Rust codebases that aren't doing high-peformance data structures, C interop, or bare-metal stuff, it's typical to write no unsafe code at all. I'm not sure who told you otherwise, but they have no idea what they're talking about.

Re: Significant raise of reports

#33

Post by 0x3f »

Why don't we just pagerank github contributors? Merged PRs approved by other quality contributors improves rank. New PRs tagged by a bot with the rank of the submitter. Add more scoring features (account age? employer?) as desired.

Re: Significant raise of reports

#34

Post by tptacek »

dspillett wrote: post #15
psyklic wrote: post #10

Earlier quoted context omitted.

> Was software made before 2000 better? At the time of release, yes. They had to ensure the software worked before printing CDs and floppies. Nowadays they release buggy versions that users essentially test for them.

Also in terms of security, there was generally a much smaller potential attack surface and those surfaces were harder to reach because we were much less constantly connected.

Software has gotten drastically more secure than it was in 2000. It's hard to comprehend how bad the security picture was in 2000. This very much, extremely includes Linux.

Re: Significant raise of reports

#35

Post by adrian_b »

glimshe wrote: post #4

The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppies, it had to survive an amazing quantity of tests that are mostly neglected nowadays since updates are easy to distribute." Was so…

It is hard to say which of the 2 is the reason, more likely both, i.e. lower complexity enabled more exhaustive testing.

In any case some of the software from before 2000 was definitely better than today, i.e. it behaved like being absolutely foolproof, i.e. nothing that you could do could cause any crash or corrupted data or any other kind of unpredictable behavior.

However, the computers to which most people had access at that time had only single-threaded CPUs. Even if you used a preemptive multitasking operating system and a heavily multi-threaded application, executing it on a single-threaded CPU was unlikely to expose subtle bugs due to race conditions, that might have been exposed on a multi-core CPU.

While nowadays there exists no standard operating system that I fully trust to never fail in any circumstance, unlike before 2003, I wonder whether this is caused by a better quality of the older programs or by the fact that it is much harder to implement software concurrency correctly on systems with hardware parallelism.

Re: Significant raise of reports

#36

Post by ModernMech »

glimshe wrote: post #4

The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppies, it had to survive an amazing quantity of tests that are mostly neglected nowadays since updates are easy to distribute." Was so…

Depends what you mean by better. It crashed more and there was a lot of data loss, but it wasn't explicitly evil so maybe on measure it was better.

Re: Significant raise of reports

#37

Post by panstromek »

noosphr wrote: post #25
Sharlin wrote: post #9

Earlier quoted context omitted.

Around 70% of security vulnerabilities are about memory safety and only exist because software is written in C and C++. Because most vulnerabilities are in newly written code, Google has found that simply starting writing new code in Rust (rather than trying to rewrite existing codebases) quickly brings the number of found vulnerabilities down drastically.

And to a good approximation all real world Rust uses unsafe everywhere. So we now have a new code base in an undefined language which still has memory bugs. This is progress.

The parent comments references real world data from Google: https://security.googleblog.com/2024/09/eliminating-memory-s...

Re: Significant raise of reports

#38

Post by bombcar »

glimshe wrote: post #4

The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppies, it had to survive an amazing quantity of tests that are mostly neglected nowadays since updates are easy to distribute." Was so…

It was the best of times, it was the worst of times.

Best/better because yes, QA actually existed and was important for many companies - QA could "stop ship" before the final master was pressed if they found something (hehe as it was usually games) "game breaking". If you search around on folklore or other historical sites you can find examples of this - and programmers working all night with the shipping manager hovering over them ready to grab the disk/disc and run to the warehouse.

HOWEVER, updates did exist - both because of bugs and features, and because programmers weren't perfect (or weren't spending space-shuttle levels of effort making "perfect code" - and even voyager can get updates iirc). Look at DooM for an example - released on BBS and there are various versions even then, and that's 1994 or so?

But it was the "worst" in that the frameworks and code were simply not as advanced as today - you had to know quite a bit about how everything worked, even as a simple CRUD developer. Lots of protections we take for granted (even in "lower level" languages like C) simply didn't exist. Security issues abounded, but people didn't care much because everything was local (who cares if you can r00t your own box) - and 2000 was where the Internet was really starting to take off and everything was beginning to be "online" and so issues were being found left and right.

Re: Significant raise of reports

#39

Post by SoftTalker »

0x3f wrote: post #33

Why don't we just pagerank github contributors? Merged PRs approved by other quality contributors improves rank. New PRs tagged by a bot with the rank of the submitter. Add more scoring features (account age? employer?) as desired.

It will be gamed, just as pagerank was.

Re: Significant raise of reports

#40

Post by bombcar »

JumpCrisscross wrote: post #23
Shank wrote: post #7

Important to note that this is a comment on this article: https://lwn.net/Articles/1065586/ .

“Reversing was already mostly a speed-bump even for entry-level teams, who lift binaries into IR or decompile them all the way back to source. Agents can do this too, but they can also reason directly from assembly. If you want a problem better suited to LLMs than bug hunting, program translation is a good place to start.” Huh. Direct debugging, in assembly. At that point, why not jump down to machine code?

Decompiled assembly is basically machine code; without recreating the macros that make assembly "high level" you're as close to machine code as you're going to get unless you're trying to exploit the CPU itself.
Post reply on HN