Dnia 2024-02-24, o godz. 19:44:44
Jeffrey Walton <noloader@gmail.com> napisał(a):

On Sat, Feb 24, 2024 at 7:37 PM Andy Smith <andy@strugglers.net>
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) <xani666@gmail.com>
GnuPG: 0xEA8ACE64
https://devrandom.eu

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Feb 24, 2024 at 07:44:44PM -0500, Jeffrey Walton wrote:

On Sat, Feb 24, 2024 at 7:37 PM Andy Smith <andy@strugglers.net> 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 <std_disclaimer.h>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dnia 2024-02-25, o godz. 11:22:50
Alain D D Williams <addw@phcomp.co.uk> 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 <andy@strugglers.net>
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) <xani666@gmail.com>
GnuPG: 0xEA8ACE64
https://devrandom.eu

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)