Re: Postel's Law (Was Re: Inclusive terminology (instead of master/slave) for network bonding/LACP)
Dnia 2024-02-25, o godz. 11:22:50 Alain D D Williams napisał(a): > On Sat, Feb 24, 2024 at 07:44:44PM -0500, Jeffrey Walton wrote: > > On Sat, Feb 24, 2024 at 7:37 PM Andy Smith > > wrote: > > > > > > [...] > > > Turning back more to protocol design, we have spent decades > > > walking back Postel's Law as we find more and more ways that > > > being liberal in what our software accepts is untenable in the > > > face of a hostile Internet. > > > > ++. Postel's Law is a disaster nowadays. It was fine back in the > > 1980's, but it is dangerous in the toxic environments of today. > > > > Here's what we teach our developers: Look for any reason you can to > > reject the data. If you can't find a reason, then begrudgingly > > perform the processing or transformation. > > There is a difference between not doing validation (eg a field being > numeric) and flexibility (eg a line length being 100 bytes which is > more than the specified 80 bytes). This is what Postel is talking > about. ...and how you would even handle it ? The DB field is 80 characters, do you want to just truncate it ? Or oversize the DB? what if DB field have that 100 bytes but someone sends 101? If the numeric field can be hex,dec,oct number or a string representing one of those (octal representation in particular is satan that claimed bugs in many projects), together with locale-specific dots dashes and commas separating thousands, that's plenty of code that can go wrong vs "okay this number is in range, job done" Yes of course there is a diffence between validation and flexibility but flexibility of protocol should only extend to backward compability, where it doesn't cost you too much, and not indefinitely. Not to be flexible just so someone can half-ass the implementation and still have it "work" because other servers cover up for the errors with being "flexible". There is a case for leeway in user-facing stuff - nobody wants to hunt for trailing whitespace in their forms just because they dared to copy-paste - but protocols had way too much leeway *because* most implementations ignored the second part, "be conservative in what you do" and frankly sent fucked up stuff that your implementation still needed to work with if it was a common open protocol. e-mail being particular example, oh the hundreds of problems with "our" mail servers that could be summed up by "your implementation pisses on RFC and that's why our mail server doesn't get your mail"... -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64 https://devrandom.eu
Re: Postel's Law (Was Re: Inclusive terminology (instead of master/slave) for network bonding/LACP)
On Sat, Feb 24, 2024 at 07:44:44PM -0500, Jeffrey Walton wrote: > On Sat, Feb 24, 2024 at 7:37 PM Andy Smith wrote: > > > > [...] > > Turning back more to protocol design, we have spent decades walking > > back Postel's Law as we find more and more ways that being liberal > > in what our software accepts is untenable in the face of a hostile > > Internet. > > ++. Postel's Law is a disaster nowadays. It was fine back in the > 1980's, but it is dangerous in the toxic environments of today. > > Here's what we teach our developers: Look for any reason you can to > reject the data. If you can't find a reason, then begrudgingly perform > the processing or transformation. There is a difference between not doing validation (eg a field being numeric) and flexibility (eg a line length being 100 bytes which is more than the specified 80 bytes). This is what Postel is talking about. Otherwise I completely agree: validate, validate, validate - if I accept your bad data then it becomes my problem, if I reject it then you have to fix it. Unfortunately people will complain if you do this "everyone accepts the data", to which I reply "please tell me exactly what it means" - which should shut them up. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include
Re: Postel's Law (Was Re: Inclusive terminology (instead of master/slave) for network bonding/LACP)
Dnia 2024-02-24, o godz. 19:44:44 Jeffrey Walton napisał(a): > On Sat, Feb 24, 2024 at 7:37 PM Andy Smith > wrote: > > > > [...] > > Turning back more to protocol design, we have spent decades walking > > back Postel's Law as we find more and more ways that being liberal > > in what our software accepts is untenable in the face of a hostile > > Internet. > > ++. Postel's Law is a disaster nowadays. It was fine back in the > 1980's, but it is dangerous in the toxic environments of today. > Postel's law works on user-interfaced data far better than protocols. > Here's what we teach our developers: Look for any reason you can to > reject the data. If you can't find a reason, then begrudgingly perform > the processing or transformation. On flip-side it's terrible idea to do that on user-entered data. Yes, security wise it's a great idea, but usability-wise it generates annoyances at every step. Like, if say user enters a data (say a token from mail 2FA) with extra spaces, the "accept only the perfectly good data" would prompt to tell them to sod off and try again", instead of just cutting the whitespaces out and checking the token. Similarly if the site requires bank account number most people don't type it, they copy it is not accepting the long string of numbers just because it had some whitespaces added for better presentation just annoys the users. And that pre-processing often (if it is a website) can be done client side so server code can keep its tight and secure processing without compromising. -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64 https://devrandom.eu
Re: Postel's Law (Was Re: Inclusive terminology (instead of master/slave) for network bonding/LACP)
On Sat, Feb 24, 2024, 6:37 PM Andy Smith wrote: > Hi, > > On Sat, Feb 24, 2024 at 04:54:12PM +, Alain D D Williams wrote: > > I sometimes think that something similar to Postel's Law but applied to > human > > interactions would be useful. However that is wishful thinking > > > I'm not saying DON'T give people the benefit of the doubt, but just > always be aware that when you do there will be people who take > advantage of that. > > Turning back more to protocol design, we have spent decades walking > back Postel's Law as we find more and more ways that being liberal > in what our software accepts is untenable in the face of a hostile > Internet. > Quoting Paul Vixie 30 years ago at the Usenix technical conference (author of various RFCs: DHCP, NNTP): "Its important to remember that the internet escaped from the lab long before we could put it into anything like production form. It's equally important that our masters do not learn that". Thanks, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting > >
Re: Postel's Law (Was Re: Inclusive terminology (instead of master/slave) for network bonding/LACP)
On Sat, Feb 24, 2024 at 7:37 PM Andy Smith wrote: > > [...] > Turning back more to protocol design, we have spent decades walking > back Postel's Law as we find more and more ways that being liberal > in what our software accepts is untenable in the face of a hostile > Internet. ++. Postel's Law is a disaster nowadays. It was fine back in the 1980's, but it is dangerous in the toxic environments of today. Here's what we teach our developers: Look for any reason you can to reject the data. If you can't find a reason, then begrudgingly perform the processing or transformation. Jeff
Postel's Law (Was Re: Inclusive terminology (instead of master/slave) for network bonding/LACP)
Hi,
On Sat, Feb 24, 2024 at 04:54:12PM +, Alain D D Williams wrote:
> I sometimes think that something similar to Postel's Law but applied to human
> interactions would be useful. However that is wishful thinking
The basic assumption that people mean well is how con artists and
high pressure sales tactics have operated since the dawn of
communication ("Oh, you can't afford the vacuum cleaner? I really
shouldn't, but let me just call my boss because I really want to
help you…").
Although at least with con artists there is the other thing of
"can't con an honest John".
I'm not saying DON'T give people the benefit of the doubt, but just
always be aware that when you do there will be people who take
advantage of that.
Turning back more to protocol design, we have spent decades walking
back Postel's Law as we find more and more ways that being liberal
in what our software accepts is untenable in the face of a hostile
Internet.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
