4 ms·

> Re: ...C and C++ memory vulnerabilities, I'd say maybe, see: Rust In general, yes. However, I hate Rust; my software wouldn't exist if I had to write it in

> Re: ...C and C++ memory vulnerabilities, I'd say maybe, see: Rust In general, yes. However, I hate Rust; my software wouldn't exist if I had to write it in Rust. [1] So I hope there would be a way for me to justify using C, along with a plan to minimize memory vulnerabilities. In my case, my plan is to fuzz, use every one of the fuzz paths found as a test case, and ensure all of those test cases come out clean in sanitizers and Valgrind. Oh, and I'll also do error injection, like SQLite [2], to exercise even more paths, and those paths will also have to come out clean. [1]: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-in-memory-safety/ https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i... [2]: https://www.sqlite.org/testing.html#anomaly_testing https://www.sqlite.org/testing.html#anomaly_testing

alilleybrinker 3y ago
At the moment there's an effort from the Office and the National Cyber Director (ONCD), CISA, NSF, DARPA, and OMB to encourage a move to memory safe languages, including but not limited to Rust (see [1]). This included an RFI for which there were many responses, including a number of major tech companies (Microsoft, Google, others). The general consensus supports a move to memory safe languages, BUT many of the respondents also caution about the need to prioritize and carefully manage such a transition, and the need to continue to support and assure code written in memory unsafe languages using other assurance techniques like fuzzing, integration testing, unit testing, static code analysis, and more. Hopefully that helps explain where things stand at the moment regarding at least US movement on this topic, and also to assuage concerns about a unilateral mandate that things get rewritten in Rust (or another language). [1]: https://www.whitehouse.gov/oncd/briefing-room/2023/08/10/fact-sheet-office-of-the-national-cyber-director-requests-public-comment-on-open-source-software-security-and-memory-safe-programming-languages/ https://www.whitehouse.gov/oncd/briefing-room/2023/08/10/fac...
- gavinhoward 3y ago
  I know. I also know that despite some having caution, there are those that would speed ahead with RIIR.
mustache_kimono 3y ago
> So I hope there would be a way for me to justify using C, along with a plan to minimize memory vulnerabilities. If the desire is -- you would like to create new software in C because you like C, I think that presents some really difficult questions in this framework, simply because a reasonable alternative exists. First, I think you have to ask: What kind of programs at you writing? Are they FOSS? Do you sell them? Are they likely to cause "damages"? If what you are doing is writing software for the joy of writing software, I'm not sure you have much to worry about. If you're writing a bank transaction server, exposed to untrusted inputs, in C and you're selling this software, you might have something to worry about, because there exists a reasonable alternative in Rust.
- gavinhoward 3y ago
  They are FOSS, but they are for a business, so yes, I will be affected. Rust is unfortunately not a reasonable alternative in some cases. As an example, my software needs just a C compiler to build itself. You can build my software completely with: tcc -run bootstrap/boostrap.c tcc This is because my software includes a build system meant to bootstrap other software. This use case is a good reason to avoid Rust. Another reason Rust may not be reasonable is the pervasiveness of async. Personally (not in general), async does not work for me. Rust is not the last word in programming languages. I am working on an alternative that will not only not have async, but will have more static analysis because destructors will be guaranteed to run. If you had read my post, you would know that I am planning to rewrite my stuff in that language as soon as possible. If Rust becomes required, I would be forced to stop work on that language, and progress would slow down. There are valid reasons to use C, even for software that handles untrusted inputs.
  - mustache_kimono 3y ago
    > Rust is unfortunately not a reasonable alternative in some cases. Sure, and tort law is a flexible framework, so you will be allowed to make that argument. The only problem is if your software blows up in a way Rust was meant to prevent.
Gibbon1 3y ago
Broken record. C's memory issues can be fixed or mitigated. The reason they haven't been is because of WG21 C++ standards committee) and WG14 (C standards committee).
- gavinhoward 3y ago
  Yeah, it bothers me. That is why I am working on my own language.
trealira 3y ago
You could hope for hardware support for security using a CHERI ISA [1]. You could also try proving your programs correct using something like Frama-C, or do it by hand like Dijkstra did. [1]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
- gavinhoward 3y ago
  I would, but my programs use structured concurrency; I don't know how well Frama-C would help. If someone paid me to, I'd do it in a heartbeat. For CHERI, I want my software to be safe on unsafe platforms. I am building a memory-safe language that I will rewrite my software in.

alilleybrinker 3y ago

At the moment there's an effort from the Office and the National Cyber Director (ONCD), CISA, NSF, DARPA, and OMB to encourage a move to memory safe languages, including but not limited to Rust (see [1]). This included an RFI for which there were many responses, including a number of major tech companies (Microsoft, Google, others). The general consensus supports a move to memory safe languages, BUT many of the respondents also caution about the need to prioritize and carefully manage such a transition, and the need to continue to support and assure code written in memory unsafe languages using other assurance techniques like fuzzing, integration testing, unit testing, static code analysis, and more. Hopefully that helps explain where things stand at the moment regarding at least US movement on this topic, and also to assuage concerns about a unilateral mandate that things get rewritten in Rust (or another language). [1]: https://www.whitehouse.gov/oncd/briefing-room/2023/08/10/fact-sheet-office-of-the-national-cyber-director-requests-public-comment-on-open-source-software-security-and-memory-safe-programming-languages/ https://www.whitehouse.gov/oncd/briefing-room/2023/08/10/fac...

gavinhoward 3y ago
I know. I also know that despite some having caution, there are those that would speed ahead with RIIR.

mustache_kimono 3y ago

> So I hope there would be a way for me to justify using C, along with a plan to minimize memory vulnerabilities. If the desire is -- you would like to create new software in C because you like C, I think that presents some really difficult questions in this framework, simply because a reasonable alternative exists. First, I think you have to ask: What kind of programs at you writing? Are they FOSS? Do you sell them? Are they likely to cause "damages"? If what you are doing is writing software for the joy of writing software, I'm not sure you have much to worry about. If you're writing a bank transaction server, exposed to untrusted inputs, in C and you're selling this software, you might have something to worry about, because there exists a reasonable alternative in Rust.

gavinhoward 3y ago
They are FOSS, but they are for a business, so yes, I will be affected. Rust is unfortunately not a reasonable alternative in some cases. As an example, my software needs just a C compiler to build itself. You can build my software completely with: tcc -run bootstrap/boostrap.c tcc This is because my software includes a build system meant to bootstrap other software. This use case is a good reason to avoid Rust. Another reason Rust may not be reasonable is the pervasiveness of async. Personally (not in general), async does not work for me. Rust is not the last word in programming languages. I am working on an alternative that will not only not have async, but will have more static analysis because destructors will be guaranteed to run. If you had read my post, you would know that I am planning to rewrite my stuff in that language as soon as possible. If Rust becomes required, I would be forced to stop work on that language, and progress would slow down. There are valid reasons to use C, even for software that handles untrusted inputs.
- mustache_kimono 3y ago
  > Rust is unfortunately not a reasonable alternative in some cases. Sure, and tort law is a flexible framework, so you will be allowed to make that argument. The only problem is if your software blows up in a way Rust was meant to prevent.

Gibbon1 3y ago

Broken record. C's memory issues can be fixed or mitigated. The reason they haven't been is because of WG21 C++ standards committee) and WG14 (C standards committee).

gavinhoward 3y ago
Yeah, it bothers me. That is why I am working on my own language.

trealira 3y ago

You could hope for hardware support for security using a CHERI ISA [1]. You could also try proving your programs correct using something like Frama-C, or do it by hand like Dijkstra did. [1]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

gavinhoward 3y ago
I would, but my programs use structured concurrency; I don't know how well Frama-C would help. If someone paid me to, I'd do it in a heartbeat. For CHERI, I want my software to be safe on unsafe platforms. I am building a memory-safe language that I will rewrite my software in.