|
Is it worthwhile improving the current C code to a 'hardened'
programming standard?� Example - Joint Strike Fighter standards https://www.stroustrup.com/JSF-AV-rules.pdf - NASA JPL standards https://andrewbanks.com/wp-content/uploads/2019/07/JPL_Coding_Standard_C.pdf - MISRA https://misra.org.uk/LinkClick.aspx?fileticket=vfArSqzP1d0%3d&tabid=57 What effort would be required for 'hardening'? If not a full 'hardening', is it worthwhile to use the hardening/vulnerability/guideline-fail reporting tools to identify and fix the worst vulnerabilities or to grab the low-hanging fruit? Anyone with experience with 'hardening' C code? (I don't) But first, what's the problem with the ntpsec C code. Is there an issue with vulnerabilities in the current C code, uncertainty with possible unknown vulnerabilities in the current code, or is the concern one of introducing vulnerabilities in the future as the C code is maintained or new functionality added? Or is the answer to that "yes". Is 'hardening' a solution or just an improvement? I assume you're still vulnerable where the hardening guidelines failed or weren't ideally followed? Is moving to a new language the better solution? If moving to another language is inevitable, if that move is selected as a goal for the next year, is 'hardening' the ntpsec C code still worthwhile? - Could 'hardening' be done and in place before the move to another language is complete. For what benefit. - Or would the 'hardened' C code be replaced weeks later by code in a new language. Or would new language code be in place in the same or similar time (sooner?), if 'hardening' efforts were instead put on moving. - If a full 'hardening' isn't worthwhile, is some 'hardening' effort worthwhile. Regards, Michael |
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
