5 ms·

Actually C is an excellent choice for security relevant systems software because the issues for developing in C are well understood and can easily be mitigated

Actually C is an excellent choice for security relevant systems software because the issues for developing in C are well understood and can easily be mitigated by following 30 years worth of best practice patterns and using the correct development tools. The issue is developers are not using the tools or following the best practices because they think they know better than 30 years worth of experience or get caught up in bikeshedding about ideology, licenses and which line the curly braces go on.

serbaut 13y ago
Can you link to the 30 years of best practice document, I must have missed it.
- spiralpolitik 13y ago
  A good place to start: http://www.amazon.com/The-CERT-Secure-Coding-Standard/dp/0321563212/ http://www.amazon.com/The-CERT-Secure-Coding-Standard/dp/032... Online: https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Coding+Standard https://www.securecoding.cert.org/confluence/display/seccode... Others: http://www.amazon.com/Secure-Coding-Edition-Software-Engineering/dp/0321822137/ http://www.amazon.com/Secure-Coding-Edition-Software-Enginee... http://www.amazon.com/Style-Guidelines-Programming-Professional-Programmers/dp/0131168983/ http://www.amazon.com/Style-Guidelines-Programming-Professio... http://www.amazon.com/C-Traps-Pitfalls-Andrew-Koenig/dp/0201179288/ http://www.amazon.com/C-Traps-Pitfalls-Andrew-Koenig/dp/0201...
  - Crito 13y ago
    Another good read (it probably does not reflect how you want to write C code, the rule about dynammic allocation is probably extreme if you are not writing code to fly spaceships, but I think it is good to read regardless): http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
betterunix 13y ago
"Actually C is an excellent choice for security relevant systems software because the issues for developing in C are well understood and can easily be mitigated by following 30 years worth of best practice patterns and using the correct development tools." Nevermind the copious undefined behavior, the fact that C programmers sometimes struggle to figure out what a valid C expression actually does, the fact that C programmers have to choose between code bloat and using "goto" for finalization, the fact that there are no standard error handling constructs, the fact that strings are null terminated, the lack of a standardized way to determine array lengths at runtime, etc., etc., etc. Even something as simple as this: int f(int x, int y) { return x + y; } Can lead to undefined behavior in C: https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow https://www.securecoding.cert.org/confluence/display/seccode... Basically C should be at the bottom of the list of languages that programmers choose for cryptography or security software.
jobigoud 13y ago
C and C++ are specifically discouraged as programming languages in "Cryptography Engineering" (Niels Ferguson, Bruce Schneier, Tadayoshi Kohno, 2010).

serbaut 13y ago

Can you link to the 30 years of best practice document, I must have missed it.

spiralpolitik 13y ago
A good place to start: http://www.amazon.com/The-CERT-Secure-Coding-Standard/dp/0321563212/ http://www.amazon.com/The-CERT-Secure-Coding-Standard/dp/032... Online: https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Coding+Standard https://www.securecoding.cert.org/confluence/display/seccode... Others: http://www.amazon.com/Secure-Coding-Edition-Software-Engineering/dp/0321822137/ http://www.amazon.com/Secure-Coding-Edition-Software-Enginee... http://www.amazon.com/Style-Guidelines-Programming-Professional-Programmers/dp/0131168983/ http://www.amazon.com/Style-Guidelines-Programming-Professio... http://www.amazon.com/C-Traps-Pitfalls-Andrew-Koenig/dp/0201179288/ http://www.amazon.com/C-Traps-Pitfalls-Andrew-Koenig/dp/0201...
- Crito 13y ago
  Another good read (it probably does not reflect how you want to write C code, the rule about dynammic allocation is probably extreme if you are not writing code to fly spaceships, but I think it is good to read regardless): http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

betterunix 13y ago

"Actually C is an excellent choice for security relevant systems software because the issues for developing in C are well understood and can easily be mitigated by following 30 years worth of best practice patterns and using the correct development tools." Nevermind the copious undefined behavior, the fact that C programmers sometimes struggle to figure out what a valid C expression actually does, the fact that C programmers have to choose between code bloat and using "goto" for finalization, the fact that there are no standard error handling constructs, the fact that strings are null terminated, the lack of a standardized way to determine array lengths at runtime, etc., etc., etc. Even something as simple as this: int f(int x, int y) { return x + y; } Can lead to undefined behavior in C: https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow https://www.securecoding.cert.org/confluence/display/seccode... Basically C should be at the bottom of the list of languages that programmers choose for cryptography or security software.

jobigoud 13y ago

C and C++ are specifically discouraged as programming languages in "Cryptography Engineering" (Niels Ferguson, Bruce Schneier, Tadayoshi Kohno, 2010).