Curl’s backdoor threat

Re:Curl’s backdoor threat by sitkack on Tuesday September 12, 2017 @08:49AM (#15226827)

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

Re:Curl’s backdoor threat by sitkack on Tuesday September 12, 2017 @11:30AM (#15228087)

If you could infer a spec from the existing code, you have at least a 100M product on your hands.

[ Parent | on HN ]

Re:Curl’s backdoor threat by SCHiM on Tuesday September 12, 2017 @12:07PM (#15228441)

And probably solved the halting problem too ;)

[ Parent | on HN ]