12 ms·

I'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 stu

I'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 national security threatening devices like phones or cyberphysical devices like self-driving cars and we would be the better for it in under a decade. We could even have taxes to give breathing room during a transitionary period to encourage it before outright banning it, but we don't. We don't because so often it is less of a hassle for the government to trust the private sector that it is to take some real position on the regulatory issues that matter. This will probably always be the case until the government is able to evaluate talent and pay salaries in accordance with that talent as the private sector is.

SV_BubbleTime 5y ago
If there is one thing politicians are surely better at it than programmers is making decisions about what programming languages should be used! /s Yes on theme, but no on ”there aught to be a law” that bans C/C++ because of an evolving goal of memory safety. When Rust++ comes out surely there will be people complaining that Rust isn’t safe, and so on. Best case is you make the consequence punishable (as was described in the article).
- mikepurvis 5y ago
  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 thing is a lightening rod for a lot of software folks, but it does have the nice property that it's proactive; you don't have to wait around for the obviously-unsafe practice to blow up in someone's face before you can do something about it. And no one wants to have to get licensed to write some crud app in NodeJS. But maybe these kinds of high-stakes modules related to encryption, security, and so on could be a place to start with it; if you're going to work in these areas, and offer your work to the public (for money or otherwise), then you either need to be licensed by the professional body, or clearly advertise in the header of each file that the work has not be overseen by a licensed professional. That's the kind of arrangement that could do things like specify languages, methods, interfaces, and so on.
  - dylan604 5y ago
    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?
    - platinumrad 5y ago
      Green Hills with its decades of DoD contracts versus the left wing browser company. Gee I wonder who would win?
    - NavinF 5y ago
      Yep, and what happens when the committee (perhaps correctly) chooses a proprietary language as the safest language? Anyone making essential software would end up writing code like this: https://i.imgur.com/8S6JbDS.png https://i.imgur.com/8S6JbDS.png (labview; Haven't used it in 10 years, but I'm pretty sure it is 100% memory safe) 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.
    - mikepurvis 5y ago
      But the point of this is that it isn't the "government involved." As with other professional pursuits, the government says "we don't have the desire, expertise, or agility needed to make these decisions in-house, so we designate this organization to be our regulator of it." For example, here's the Professional Engineers Act in Ontario: https://www.ontario.ca/laws/regulation/900941 https://www.ontario.ca/laws/regulation/900941 None of it has anything to do with which tools or methods are used for the practice of engineering— it's all defining jurisdiction and constitutional meta-details about how the leadership is to be selected, term lengths, etc. So no one can achieve regulatory capture about what kind of concrete is to be used in bridges in Ontario by lobbying the Ontario government; you'd have to lobby the PEO. Maybe your argument is that they're effectively equivalent, but they're really not— the PEO is a pretty different kind of organization from just another government office.
- rapsey 5y ago
  > If there is one thing politicians are surely better at it than programmers is making decisions about what programming languages should be used! /s Programmers aren't that good at it either.
flatline 5y ago
I had never thought of passing legislation against unsafe languages. It sounds like the type of thorny legislative issue that leaves you with a half broken system, like all the cookie notices that currently abound. Nice in spirit, impossible in practice. Regulation could be more sensible but it’s all in the enforcement. There’s nothing preventing organizations from adopting safer coding languages and practices right now, a little incentive may help a bit but I think only so far.
Hermitian909 5y ago
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 encourage you to read the paper "Some Were Meant For C"[0] on why C still doesn't have a real replacement (though it could in the future). [0] https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-preprint.pdf https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-p...
- nine_k 5y ago
  Certainly there's no boundary that clearly delineates "safe" and "unsafe" languages. But certain languages (like C and C++, for instance) have built-in footguns. They were built in for various important reasons, but right now many of these reasons are not as pressing anymore. We can take something like Ada, Rust, OCaml instead, or at least use the extensive tooling that allows to statically check programs written in (a rather wide subset of) C and detect great many classical pitfalls. So I'd say that it's not about safe languages, but mostly about safe methods of development for critical software, methods that remove large classes of defects that are commonly exploitable. This, of course, can be only one layer of protection; the OS and the hardware design should also do their part. Advanced devices, like desktop and phone CPUs, have some very good hardware features for protection, like MMUs, w^x bits for RAM pages, secure enclaves, etc. Simpler devices (like IoT SoCs) often don't, and they can be potentially cracked into more easily.
  - Karrot_Kream 5y ago
    Then punish defects. Give programmers the freedom to define their semantic space, but make sure to punish profit-seeking entities for insecure behavior. It's not that simple of course (it's easier for FB to pay a fine than a startup, for example), but we need to enforce the cost of defects at the organization level. I mean, there's also a world where FB apologizes about how they "forgot" to remove `unsafe` from a part of Rust code.
yashap 5y ago
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.
- nine_k 5y ago
  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.
  - conradev 5y ago
    While Fuschsia's microkernel architecture has a lot of security benefits, the microkernel (Zircon) is still written in C++
    - littlestymaar 5y ago
      Related: > Our kernel, Zircon, [is not in Rust](https://twitter.com/cpuGoogle/status/1397265884251525122 https://twitter.com/cpuGoogle/status/1397265884251525122). Not yet anyway. But it is in [a nice, lean subset of C++](https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/cxx https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/...) which I consider a vast improvement over C. https://blog.cr0.org/2021/06/a-few-thoughts-on-fuchsia-security.html https://blog.cr0.org/2021/06/a-few-thoughts-on-fuchsia-secur...
    - pjmlp 5y ago
      For the time being yes. They are now starting to rewrite OS components in Rust, and I wouldn't be surprised if that happens to Zircon as well, it stared as a C anyway, and thus already suffered one rewrite.
platinumrad 5y ago
You have an awfully rosy view of how regulation of programming languages would play out. What will happen (and this is already de facto the case in many "safety-critical" industries) is that Rust is banned and everyone is forced to write straightjacketed C89 and C++03. There's already a congressman on the record complaining about a "native Nigerian" committing code to Rust.
- littlestymaar 5y ago
  > There's already a congressman on the record complaining about a "native Nigerian" committing code to Rust. Wow. It comes from the Libra hearing I guess? By any chance, do you have an link to the exact quote? Edit: as hsod answered below (I don't really get why this answer was flagged) the congressman isn't really “complaining” and it's not about a Nigerian committing to Rust, but to Libra itself.
  - hsod 5y ago
    It’s around 30 seconds of this clip https://www.c-span.org/video/?c4808083/user-clip-rust-language-chosen https://www.c-span.org/video/?c4808083/user-clip-rust-langua... “I went ahead and did a GitHub search on who’s actually leading the development on the Libra core side and it looks like, I think it’s gonna be international because it looks like a native Nigerian that’s actually building the actual Libra core in front of the code development of Libra core” - congressman Denver Riggleman (R-VA) He lost his seat in 2020
    - roflc0ptic 5y ago
      It's an unsettling combination of literacy and illiteracy there.
  - deleted 5y ago
    [deleted]
MichaelMoser123 5y ago
Where is your legislation supposed to draw the line? In Rust you need to have occasional unsafe code - you can't even have a double linked list or bidirectional graph without unsafe code. Would you also outlaw jni calls in java?
- staticassertion 5y ago
  The way this would likely end up being handled is the same as any other compliance. You define the threat model for your application and then justify why you're safe. In this case we'd be adding an explicit point to ensure that there are controls for attackers who can exploit memory safety issues. You could end up with controls like: 1. We sandbox our code, so even though it's C we feel that we're safe 2. We use a memory safe language to reduce the risk of memory safety issues 3. We sanitizer inputs before providing them to the program etc etc What ends up being accepted as legitimate would be up to the auditors/ generally a matter of consensus.
  - MichaelMoser123 5y ago
    would that imply that the state would have to review the design and implementation of every system under their jurisdiction? I think that would be a bit heavy for everyone involved.
    - staticassertion 5y ago
      This is already the case.
- FractalHQ 5y ago
  Can’t unsafe Rust (when properly isolated) exist within a larger codebase that, as a whole, can still be considered safe?
  - lionkor 5y ago
    The same way you can write safe modern C++ and only use unsafe features of the language when its necessary and isolated, but thats also considered unsafe, so Rust should be, too
rapjr9 5y ago
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 fascination with creating a new language every time we want to add some features? Is it the fame of creating and naming your own computer language? From a security perspective creating a new language reduces security because it will never have been as thoroughly vetted as the old languages.
- roca 5y ago
  Because safety requires that the language prevent you from doing things and libraries don't have much ability to do that. 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.
- staticassertion 5y ago
  Saying that Java is safe therefor you can write safe C is not actually sensible. The JVM is a virtual machine that runs user's programs, and those programs are in a memory safe language. That doesn't mean the JVM is memory safe... at all. 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.
zbyforgotpass 5y ago
Instead of banning unsafe languages how about allowing for tort liability for software? There is a big difference in law between software and other engineering like building bridges. It used to be that software failures were not as severe as a collapsing bridge - but we are close to the point where it reverses.
RandomLensman 5y ago
Even if we could clearly differentiate between "safe" and "unsafe" languages, what use cases and devices go on the list? Would phones really be that high up given that in environments with high security standards usually people are not allowed to carry them? What about home appliances? Could a state actor hack a bunch of stoves and burn the houses down? I can easily see some huge bureaucracy being put in place without much benefits ("Federal Programing Language Commission"?). Most high security environments have a physical component, why not learn from there? Phones could just have a physical switch to cut off microphones and antennae for example, much easier to do than trying to police millions of lines of codes to be secure.
7373737373 5y ago
"Why KeyKOS is fascinating" - https://github.com/void4/notes/issues/41 https://github.com/void4/notes/issues/41
Seirdy 5y ago
Would you consider assembly to be unsafe? High-level software written with low-level languages like this includes: - Decoders and encoders for video, images, and audio - graphics libraries - Many parts of fast cryptographic libraries This is typically for performance-related reasons.
- deleted 5y ago
  [deleted]
throwaway210222 5y ago
> We could pass a law and ban new code in unsafe languages from national security threatening devices Countries already do this. But they also put exemption clauses in the policies. Ban exemptions (in all policies) first if you want to make progress. But you won't like it.
wydfre 5y ago
What he is referencing is what I call “artificial complexity”, a way for making solving problems ludicrously wasteful in man-hours. This is primarily accomplished via limiting remixes of known technology - think for example of how easy it is to add types to Lisp and yet it took decades to be attempted publicly. It is the job of human intelligence to cause ‘discontention’ - discontent and contention. I like to think of how it as how you can make powerful gears almost seize if you understand their weaknesses properly.
matheusmoreira 5y ago
Safer languages like Rust are awesome but cannot solve all of these problems. Code reflects the programmer's understanding of the world. If this understanding is flawed, the logic will also be flawed.
raxxorrax 5y ago
This is unnecessary regulation and not a good idea. Would that also apply to runtimes, interpreters and compilers? Liability should be created where when you expose third party data. That would disincentivise data collection massively.
fouric 5y ago
> We could pass a law and ban new code in unsafe languages I can tell you exactly how this will end up: like PCI DSS.

SV_BubbleTime 5y ago

If there is one thing politicians are surely better at it than programmers is making decisions about what programming languages should be used! /s Yes on theme, but no on ”there aught to be a law” that bans C/C++ because of an evolving goal of memory safety. When Rust++ comes out surely there will be people complaining that Rust isn’t safe, and so on. Best case is you make the consequence punishable (as was described in the article).

mikepurvis 5y ago
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 thing is a lightening rod for a lot of software folks, but it does have the nice property that it's proactive; you don't have to wait around for the obviously-unsafe practice to blow up in someone's face before you can do something about it. And no one wants to have to get licensed to write some crud app in NodeJS. But maybe these kinds of high-stakes modules related to encryption, security, and so on could be a place to start with it; if you're going to work in these areas, and offer your work to the public (for money or otherwise), then you either need to be licensed by the professional body, or clearly advertise in the header of each file that the work has not be overseen by a licensed professional. That's the kind of arrangement that could do things like specify languages, methods, interfaces, and so on.
- dylan604 5y ago
  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?
  - platinumrad 5y ago
    Green Hills with its decades of DoD contracts versus the left wing browser company. Gee I wonder who would win?
  - NavinF 5y ago
    Yep, and what happens when the committee (perhaps correctly) chooses a proprietary language as the safest language? Anyone making essential software would end up writing code like this: https://i.imgur.com/8S6JbDS.png https://i.imgur.com/8S6JbDS.png (labview; Haven't used it in 10 years, but I'm pretty sure it is 100% memory safe) 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.
  - mikepurvis 5y ago
    But the point of this is that it isn't the "government involved." As with other professional pursuits, the government says "we don't have the desire, expertise, or agility needed to make these decisions in-house, so we designate this organization to be our regulator of it." For example, here's the Professional Engineers Act in Ontario: https://www.ontario.ca/laws/regulation/900941 https://www.ontario.ca/laws/regulation/900941 None of it has anything to do with which tools or methods are used for the practice of engineering— it's all defining jurisdiction and constitutional meta-details about how the leadership is to be selected, term lengths, etc. So no one can achieve regulatory capture about what kind of concrete is to be used in bridges in Ontario by lobbying the Ontario government; you'd have to lobby the PEO. Maybe your argument is that they're effectively equivalent, but they're really not— the PEO is a pretty different kind of organization from just another government office.
rapsey 5y ago
> If there is one thing politicians are surely better at it than programmers is making decisions about what programming languages should be used! /s Programmers aren't that good at it either.

flatline 5y ago

I had never thought of passing legislation against unsafe languages. It sounds like the type of thorny legislative issue that leaves you with a half broken system, like all the cookie notices that currently abound. Nice in spirit, impossible in practice. Regulation could be more sensible but it’s all in the enforcement. There’s nothing preventing organizations from adopting safer coding languages and practices right now, a little incentive may help a bit but I think only so far.

Hermitian909 5y ago

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 encourage you to read the paper "Some Were Meant For C"[0] on why C still doesn't have a real replacement (though it could in the future). [0] https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-preprint.pdf https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-p...

nine_k 5y ago
Certainly there's no boundary that clearly delineates "safe" and "unsafe" languages. But certain languages (like C and C++, for instance) have built-in footguns. They were built in for various important reasons, but right now many of these reasons are not as pressing anymore. We can take something like Ada, Rust, OCaml instead, or at least use the extensive tooling that allows to statically check programs written in (a rather wide subset of) C and detect great many classical pitfalls. So I'd say that it's not about safe languages, but mostly about safe methods of development for critical software, methods that remove large classes of defects that are commonly exploitable. This, of course, can be only one layer of protection; the OS and the hardware design should also do their part. Advanced devices, like desktop and phone CPUs, have some very good hardware features for protection, like MMUs, w^x bits for RAM pages, secure enclaves, etc. Simpler devices (like IoT SoCs) often don't, and they can be potentially cracked into more easily.
- Karrot_Kream 5y ago
  Then punish defects. Give programmers the freedom to define their semantic space, but make sure to punish profit-seeking entities for insecure behavior. It's not that simple of course (it's easier for FB to pay a fine than a startup, for example), but we need to enforce the cost of defects at the organization level. I mean, there's also a world where FB apologizes about how they "forgot" to remove `unsafe` from a part of Rust code.

yashap 5y ago

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.

nine_k 5y ago
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.
- conradev 5y ago
  While Fuschsia's microkernel architecture has a lot of security benefits, the microkernel (Zircon) is still written in C++
  - littlestymaar 5y ago
    Related: > Our kernel, Zircon, [is not in Rust](https://twitter.com/cpuGoogle/status/1397265884251525122 https://twitter.com/cpuGoogle/status/1397265884251525122). Not yet anyway. But it is in [a nice, lean subset of C++](https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/cxx https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/...) which I consider a vast improvement over C. https://blog.cr0.org/2021/06/a-few-thoughts-on-fuchsia-security.html https://blog.cr0.org/2021/06/a-few-thoughts-on-fuchsia-secur...
  - pjmlp 5y ago
    For the time being yes. They are now starting to rewrite OS components in Rust, and I wouldn't be surprised if that happens to Zircon as well, it stared as a C anyway, and thus already suffered one rewrite.

platinumrad 5y ago

You have an awfully rosy view of how regulation of programming languages would play out. What will happen (and this is already de facto the case in many "safety-critical" industries) is that Rust is banned and everyone is forced to write straightjacketed C89 and C++03. There's already a congressman on the record complaining about a "native Nigerian" committing code to Rust.

littlestymaar 5y ago
> There's already a congressman on the record complaining about a "native Nigerian" committing code to Rust. Wow. It comes from the Libra hearing I guess? By any chance, do you have an link to the exact quote? Edit: as hsod answered below (I don't really get why this answer was flagged) the congressman isn't really “complaining” and it's not about a Nigerian committing to Rust, but to Libra itself.
- hsod 5y ago
  It’s around 30 seconds of this clip https://www.c-span.org/video/?c4808083/user-clip-rust-language-chosen https://www.c-span.org/video/?c4808083/user-clip-rust-langua... “I went ahead and did a GitHub search on who’s actually leading the development on the Libra core side and it looks like, I think it’s gonna be international because it looks like a native Nigerian that’s actually building the actual Libra core in front of the code development of Libra core” - congressman Denver Riggleman (R-VA) He lost his seat in 2020
  - roflc0ptic 5y ago
    It's an unsettling combination of literacy and illiteracy there.
- deleted 5y ago
  [deleted]

MichaelMoser123 5y ago

Where is your legislation supposed to draw the line? In Rust you need to have occasional unsafe code - you can't even have a double linked list or bidirectional graph without unsafe code. Would you also outlaw jni calls in java?

staticassertion 5y ago
The way this would likely end up being handled is the same as any other compliance. You define the threat model for your application and then justify why you're safe. In this case we'd be adding an explicit point to ensure that there are controls for attackers who can exploit memory safety issues. You could end up with controls like: 1. We sandbox our code, so even though it's C we feel that we're safe 2. We use a memory safe language to reduce the risk of memory safety issues 3. We sanitizer inputs before providing them to the program etc etc What ends up being accepted as legitimate would be up to the auditors/ generally a matter of consensus.
- MichaelMoser123 5y ago
  would that imply that the state would have to review the design and implementation of every system under their jurisdiction? I think that would be a bit heavy for everyone involved.
  - staticassertion 5y ago
    This is already the case.
FractalHQ 5y ago
Can’t unsafe Rust (when properly isolated) exist within a larger codebase that, as a whole, can still be considered safe?
- lionkor 5y ago
  The same way you can write safe modern C++ and only use unsafe features of the language when its necessary and isolated, but thats also considered unsafe, so Rust should be, too

rapjr9 5y ago

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 fascination with creating a new language every time we want to add some features? Is it the fame of creating and naming your own computer language? From a security perspective creating a new language reduces security because it will never have been as thoroughly vetted as the old languages.

roca 5y ago
Because safety requires that the language prevent you from doing things and libraries don't have much ability to do that. 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.
staticassertion 5y ago
Saying that Java is safe therefor you can write safe C is not actually sensible. The JVM is a virtual machine that runs user's programs, and those programs are in a memory safe language. That doesn't mean the JVM is memory safe... at all. 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.

zbyforgotpass 5y ago

Instead of banning unsafe languages how about allowing for tort liability for software? There is a big difference in law between software and other engineering like building bridges. It used to be that software failures were not as severe as a collapsing bridge - but we are close to the point where it reverses.

RandomLensman 5y ago

Even if we could clearly differentiate between "safe" and "unsafe" languages, what use cases and devices go on the list? Would phones really be that high up given that in environments with high security standards usually people are not allowed to carry them? What about home appliances? Could a state actor hack a bunch of stoves and burn the houses down? I can easily see some huge bureaucracy being put in place without much benefits ("Federal Programing Language Commission"?). Most high security environments have a physical component, why not learn from there? Phones could just have a physical switch to cut off microphones and antennae for example, much easier to do than trying to police millions of lines of codes to be secure.

7373737373 5y ago

"Why KeyKOS is fascinating" - https://github.com/void4/notes/issues/41 https://github.com/void4/notes/issues/41

Seirdy 5y ago

Would you consider assembly to be unsafe? High-level software written with low-level languages like this includes: - Decoders and encoders for video, images, and audio - graphics libraries - Many parts of fast cryptographic libraries This is typically for performance-related reasons.

deleted 5y ago
[deleted]

throwaway210222 5y ago

> We could pass a law and ban new code in unsafe languages from national security threatening devices Countries already do this. But they also put exemption clauses in the policies. Ban exemptions (in all policies) first if you want to make progress. But you won't like it.

wydfre 5y ago

What he is referencing is what I call “artificial complexity”, a way for making solving problems ludicrously wasteful in man-hours. This is primarily accomplished via limiting remixes of known technology - think for example of how easy it is to add types to Lisp and yet it took decades to be attempted publicly. It is the job of human intelligence to cause ‘discontention’ - discontent and contention. I like to think of how it as how you can make powerful gears almost seize if you understand their weaknesses properly.

matheusmoreira 5y ago

Safer languages like Rust are awesome but cannot solve all of these problems. Code reflects the programmer's understanding of the world. If this understanding is flawed, the logic will also be flawed.

raxxorrax 5y ago

This is unnecessary regulation and not a good idea. Would that also apply to runtimes, interpreters and compilers? Liability should be created where when you expose third party data. That would disincentivise data collection massively.

fouric 5y ago

> We could pass a law and ban new code in unsafe languages I can tell you exactly how this will end up: like PCI DSS.