Re:Curl’s backdoor threat
by StavrosK on Tuesday September 12, 2017 @06:53AM
(#15226253)
That makes no sense. There has been a ton of research. C, needing to be backwards-compatible, can only implement a subset of that research. More modern languages, not having this burden, are free to implement the entirety of this research. Therefore, C can only be at most equal to new languages, and overwhelmingly likely worse.
[ Parent
| on HN ]
Makes a lot of sense. You have 2 scenarios; 1) old code base in C, rewrite in language du jour. 2) new functionality in either C or spiffy lang 2.0 (SPIFFY).
For scenario 1, all that functionality has to be duplicated, including "defects". Are you sure that the functionality is 100% there or did you miss any use cases? Decision for leaving it.
Scenario 2, new widget. Most likely, coding in SPIFFY will be a better choice.
Run old anomalous traffic on old codebase that can handle the corner cases. Run the new traffic over the safe code that covers 80% of the use cases.
Slowly expand the percentage of traffic coverable by the new safe code.
The 80 percent case can be written and coded in a small amount of time. In curls example, it is fetching a file over http 1.1 using an encoding, possibly following some redirects. Then post and put requests, then chunked uploads, downloads, then?
Need gopher and ftp? Run the old codepath.
Re:Curl’s backdoor threat
by mediocrejoker on Tuesday September 12, 2017 @10:30AM
(#15227525)
If you had a list of all the corner cases from the start, wouldn't it be easy to just cover them in the new code? I thought the point of corner cases was that they introduce bugs because we don't think of them when we design the system.
If you could infer a spec from the existing code, you have at least a 100M product on your hands.
And probably solved the halting problem too ;)