4 ms·

Get started then. We can't use something with no track record nor releases published in production systems.

by RealStickman_ 4y ago

29athrowaway 4y ago
Then rewrite in Ada or whatever. Ada has been around for a while and has been used in important projects.
- pyuser583 4y ago
  Is Ada memory safe? I don’t think it is.
  - yjftsjthsd-h 4y ago
    https://www.reddit.com/r/ada/comments/mme3jk/is_ada_memory_safe/ https://www.reddit.com/r/ada/comments/mme3jk/is_ada_memory_s... seems to think so, although unfortunately I'm not qualified to evaluate it (so take this with a medium-large grain of salt...)
  - 29athrowaway 4y ago
    It is still a significant upgrade in terms of safety over C.
    - pyuser583 4y ago
      The main argument against Ada is you can achieve a higher level of safety/convenience using C++ frameworks and code analysis tools.
      - 29athrowaway 4y ago
        The F-35 JSF project used C++, and had a draconian coding standard, and likely used all of the tools you mentioned. It was plagued with defects that costed the taxpayer billions of dollars. https://www.stroustrup.com/JSF-AV-rules.pdf https://www.stroustrup.com/JSF-AV-rules.pdf
        deleted 4y ago
        [deleted]
- yjftsjthsd-h 4y ago
  Are there TLS implementations in Ada that have a track record? I don't think that remark was aimed at the language, only pointing out that writing a new TLS library in a safer language is not exactly a trivial expenditure of resources.
  - 29athrowaway 4y ago
    The track record of OpenSSL = memory management vulnerabilities. Vulnerabilities that are preventable. Google: openssl "use-after-free" site:cvedetails.com/cve It's time to accept that C is not the tool for the job. Good programmers still make mistakes and now we have tools to catch most of those mistakes. In Rust many of those errors become compile-time errors.
    - yjftsjthsd-h 4y ago
      That's one possible reading of the situation, certainly. Another, however, is that openssl is uniquely poor quite separately from the language it happens to be implemented in. Unfortunately TLS libraries are thin enough on the ground that we can't really pick out patterns. It's like saying that microkernels are bad because HURD has serious issues; it could be true, but comparing by the well-known problem child isn't necessarily a good way to tell.
      - 29athrowaway 4y ago
        > Another, however, is that openssl is uniquely poor quite separately from the language it happens to be implemented in. There are well-known, proven solutions to the memory management problems that affect OpenSSL (a C library) in a regular basis, and there are languages that implement those solutions. Among them, Rust, Ada and others.
        Arch-TK 4y ago
        While it is likely that the issue affecting OpenSSL is memory safety related, how do you know for sure that it is and that rust would have prevented it without having a performance impact? While a language which prevents certain memory errors by design is going to be safe by design, it's entirely possible this bug is in code so hot that it has been repeatedly optimized further and further and that an equivalent implementation in rust would require an unsafe block. Now it is all great to respond to this by saying "safety should never preclude performance" but in that case, why would you write in rust when there are even safer languages such as spark? Moreover, if your secure solution is too slow, nobody will want to use it. I do agree that OpenSSL is a pile of trash, but an overwhelming amount of the crust of OpenSSL is not C related.

Get started then. We can't use something with no track record nor releases published in production systems.

29athrowaway 4y ago

Then rewrite in Ada or whatever. Ada has been around for a while and has been used in important projects.

pyuser583 4y ago
Is Ada memory safe? I don’t think it is.
- yjftsjthsd-h 4y ago
  https://www.reddit.com/r/ada/comments/mme3jk/is_ada_memory_safe/ https://www.reddit.com/r/ada/comments/mme3jk/is_ada_memory_s... seems to think so, although unfortunately I'm not qualified to evaluate it (so take this with a medium-large grain of salt...)
- 29athrowaway 4y ago
  It is still a significant upgrade in terms of safety over C.
  - pyuser583 4y ago
    The main argument against Ada is you can achieve a higher level of safety/convenience using C++ frameworks and code analysis tools.
    - 29athrowaway 4y ago
      The F-35 JSF project used C++, and had a draconian coding standard, and likely used all of the tools you mentioned. It was plagued with defects that costed the taxpayer billions of dollars. https://www.stroustrup.com/JSF-AV-rules.pdf https://www.stroustrup.com/JSF-AV-rules.pdf
      - deleted 4y ago
        [deleted]
yjftsjthsd-h 4y ago
Are there TLS implementations in Ada that have a track record? I don't think that remark was aimed at the language, only pointing out that writing a new TLS library in a safer language is not exactly a trivial expenditure of resources.
- 29athrowaway 4y ago
  The track record of OpenSSL = memory management vulnerabilities. Vulnerabilities that are preventable. Google: openssl "use-after-free" site:cvedetails.com/cve It's time to accept that C is not the tool for the job. Good programmers still make mistakes and now we have tools to catch most of those mistakes. In Rust many of those errors become compile-time errors.
  - yjftsjthsd-h 4y ago
    That's one possible reading of the situation, certainly. Another, however, is that openssl is uniquely poor quite separately from the language it happens to be implemented in. Unfortunately TLS libraries are thin enough on the ground that we can't really pick out patterns. It's like saying that microkernels are bad because HURD has serious issues; it could be true, but comparing by the well-known problem child isn't necessarily a good way to tell.
    - 29athrowaway 4y ago
      > Another, however, is that openssl is uniquely poor quite separately from the language it happens to be implemented in. There are well-known, proven solutions to the memory management problems that affect OpenSSL (a C library) in a regular basis, and there are languages that implement those solutions. Among them, Rust, Ada and others.
      - Arch-TK 4y ago
        While it is likely that the issue affecting OpenSSL is memory safety related, how do you know for sure that it is and that rust would have prevented it without having a performance impact? While a language which prevents certain memory errors by design is going to be safe by design, it's entirely possible this bug is in code so hot that it has been repeatedly optimized further and further and that an equivalent implementation in rust would require an unsafe block. Now it is all great to respond to this by saying "safety should never preclude performance" but in that case, why would you write in rust when there are even safer languages such as spark? Moreover, if your secure solution is too slow, nobody will want to use it. I do agree that OpenSSL is a pile of trash, but an overwhelming amount of the crust of OpenSSL is not C related.