> > > I don't think it's entirely fair to blame the coders who make these > > > mistakes, because a very large number of excellent programmers have > > > made a mess of DNS name decompression. ...
i shipped the crap in question as late as 1998, and excellence wasn't the problem. in this field at that time, crap was the norm, and this crap was better than most -- "excellent" if you will, by the standards of the day. this is not that day, and while crap may still be an internet norm, it is no longer excellent. here are some of the things you can be sure of: 1. somebody wrote or copied this code in C and didn't red-team it 2. somebody copied this code without tracking where they copied it from so, freebsd was unfairly maligned in the forescout report on this event; the bug was in their dhcp client, not their dns or "tcp/ip stack", and had been fixed 20 years late but still six months ago. everything else on that list was properly and fairly maligned, and ought to be grounds to wonder what other code those vendors have written or copied in C, without red-teaming it, and without tracking later changes. > > > It seems worthwhile to try to help future coders not to mess it up. as a technology action, sure. but we've got to stop writing crap generally not just in decoders. that means red-teaming things before they go out, and only dealing with vendors who can afford to do this. (C, having as it does no bounds checking, allows any pointer to be wild -- So Expect That.) "as long as people write parsers, and connect them to the internet, i'll have work." --anon -- Paul Vixie _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
