Objectives for the next year

[Eric S. Raymond]

MLewis <mlewis000 at rogers.com>:
>    Is it worthwhile improving the current C code to a 'hardened' programming
>    standard?�
> 
>    Example
>    - Joint Strike Fighter standards
>    [1]https://www.stroustrup.com/JSF-AV-rules.pdf
>    - NASA JPL standards
>    [2]https://andrewbanks.com/wp-content/uploads/2019/07/JPL_Coding_Standard_C.pdf
>    - MISRA
>    [3]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
> 
> References
> 
>    Visible links
>    1. https://www.stroustrup.com/JSF-AV-rules.pdf
>    2. https://andrewbanks.com/wp-content/uploads/2019/07/JPL_Coding_Standard_C.pdf
>    3. https://misra.org.uk/LinkClick.aspx?fileticket=vfArSqzP1d0%3d&tabid=57


Here is my judgment:

>                                                          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?

All of the above.

I *do* have experience with hardening C code - a substabtiual amount
of it has been on this project, and there was GPSD before that.  In
truth, we've already done most of the best practices. More effort
would have rapidly diminishing returns.

But the real problem is at a deeper level. C is fundamentally unsafe;
hardening - either as we've achieved it or as a hypothetical ideal -
can only be an improvement, not a solution.

I think our time would be better spent moving to a memory-safe
language than trying to harden the C code further.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>