I doubt "real" engineering is better. It's just that attacking its artifacts doesn't scale, so it looks more secure. In fact, the average bridge or skyscraper is probably absolutely riddled with serious design and manufacturing flaws
The Insecurity Industry
131–140 of 386 posts
Re: The Insecurity Industry
#132I'm not going to comment on Snowden's view of what liberal western states do when it comes to surveillance. I have my own opinion, but he's been right about stuff I'd disagreed with him in the past before so I'm gun shy about confronting his ideas again. On the topic of unsafe language though, he's absolutely right. We don't have to put up with this. We could pass a law and ban new code in unsafe languages from natio…
C and C++ are really versatile, why are there no safe libraries for them (or are there?). If you want to make buffer overflows impossible then add a library that does so and use it. If you want safer memory handling use a library. Or extend C and C++ with standard libraries that are safer to use. Java is implemented in C so anything Java can do, C can do. Many languages are actually implemented in C. What is this fas…
Example: C++ shared_ptr gives you reference counting which helps prevent use-after-free errors. However, shared_ptr can't stop you getting a raw pointer or reference to the underlying object, which can then be used to trigger a use-after-free bug.
Re: The Insecurity Industry
#133I'm not going to comment on Snowden's view of what liberal western states do when it comes to surveillance. I have my own opinion, but he's been right about stuff I'd disagreed with him in the past before so I'm gun shy about confronting his ideas again. On the topic of unsafe language though, he's absolutely right. We don't have to put up with this. We could pass a law and ban new code in unsafe languages from natio…
C and C++ are really versatile, why are there no safe libraries for them (or are there?). If you want to make buffer overflows impossible then add a library that does so and use it. If you want safer memory handling use a library. Or extend C and C++ with standard libraries that are safer to use. Java is implemented in C so anything Java can do, C can do. Many languages are actually implemented in C. What is this fas…
It's like saying "llvm is in C++, and llvm is used to compile Rust, therefor C++ is as safe as Rust". It's just not a tractable argument.
As for the rest of your post, sure, you can create a new revision of C/C++ that's memory safe - feel free to do so. It'll basically be a new language, but that's fine and has nothing to do with the parent's point, which is that we should incentivize memory safety - they didn't say it had to be a new language.
As for why people don't take that approach, it's because: it'll be a massive breaking change, so it's really no different from a completely new language. If you're going to create a completely new language you may as well take the time to fix a bunch of other issues while you're there.
edit: The above applies to libraries too. There are libraries that enforce stronger security in C++ (I want to say... IronC++? Something like that), and it basically ends up being, give or take, the cognitive overhead of a new language, but with the added bonus of no one actually using it.
> From a security perspective creating a new language reduces security because it will never have been as thoroughly vetted as the old languages.
This is unsubstantiated, and I highly doubt it is the case.
Re: The Insecurity Industry
#134Earlier quoted context omitted.
Would you refuse to use Postgres, the Linux kernel or SQLite because they’re all written in C? Certainly C and C++ have more footguns than many other languages, but highly insecure as well as highly secure software gets written in all languages. I think coming up with better/easier avenues for digital-security-breach related lawsuits and fines is a better idea than banning specific languages.
Funny that you ask: Linux kernel rather actively embraces experimental code written in Rust. And yes, for a really critical system I might consider taking something much simpler and potentially slower but formally proven correct, like seL4. Google is working on Fuchsia as a new phone / chromebook OS, and it's very much focused on bulletproof security.
Re: The Insecurity Industry
#135Re: The Insecurity Industry
#136Re: The Insecurity Industry
#137Earlier quoted context omitted.
Other industries handle this kind of thing with a layer of indirection: instead of laws from the state, the state imbues a professional body with certification power, and the body sets standards by consensus or whatever other process among their members. So if you're an architect, or lawyer, or tradesperson, or whatever, you have to do things in the manner prescribed or you lose your license. I know this kind of thin…
Anytime gov't gets involved though, you have to consider how the lobbiest will get involved. So a proponent with deep pockets that is thouroghly entreched with a language about to be "banned" decides to hire a lobbiest to convince these "well educated in all things" gov't reps. Yet proponents of "safe" languages have no cash to spend. Which language is going to get banned then?
Don't worry, the pricing will be FRAND (fair, reasonable, and non-discriminatory). You just won't be able to see the compiler and runtime sources or follow stack traces into stdlib code. For security reasons. Defense in depth, y'all.
Re: The Insecurity Industry
#138I'm not going to comment on Snowden's view of what liberal western states do when it comes to surveillance. I have my own opinion, but he's been right about stuff I'd disagreed with him in the past before so I'm gun shy about confronting his ideas again. On the topic of unsafe language though, he's absolutely right. We don't have to put up with this. We could pass a law and ban new code in unsafe languages from natio…
As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes. Yes C/C++ have more footguns than Java but there's no "hard line" in the safety differences and there are real and important things that need doing that it's not always clear can be reasonably done in another language. If you haven't, I'd encou…
I agree, though that's not intractable. There's security compliance like ISO27001, which can't say "you're secure", but can say "you've got a threat model and you take measures to address it". It's then something you document and provide evidence for as part of your compliance obligations.
If we applied the same thing to a programming language I think it could be very clear to see the differences between languages.
That's not at all to say that I think ISO27001 is a good model for security, just that we already have systems that handle very nuanced ideas, so a formal definition, or proof, etc, is not really as necessary as it may seem.
Re: The Insecurity Industry
#139I was all ready to post a reply... when I was hit by the darkest pattern of all... you must pay to do so, with no hint prior to that moment.
Substack replies are paid? Hmm. Thinking about this right now: annoying sure but why do you consider this pattern dark? I bet it reduces spam and trolling by orders of magnitude unlike say confusing cookie dialogs designed to make you surrender all your private info.
Re: The Insecurity Industry
#140I don't think you'd have to ban unsafe languages but you could pass a law that slowly decreased the amount of money the government could spend on 'unsafe' software (either through direct licensing or renting through clouds). The government is such a huge client to these companies that it'd immediately create a large financial incentive to migrate.
That's billions of dollars that will get slowly steered in the right direction.