Maybe it helps to point out that the statements "you should design your system to thoroughly validate input and reject it if it's invalid" and "there are contexts, where trying to be as flexible as possible in trying to make sense of an input" can both be true.
For example, I would agree that if you build a service, you should generally try to not to be too liberal in what you accept. Because Hyrum's Law <https://www.hyrumslaw.com/> implies that over time, this would create a more and more complex de-facto standard you (and others) need to implement. But I would also argue, that it's useful to have an interactive tool you can just throw things to and have it try and make sense of it - if I just find a Base64 string on the internet and want to know what it means, it's inconvenient to have to fully specify or convert the format, especially if I'm just doing what that tool would be doing anyway. So, this argument is a false dichotomy. Both ends of the spectrum have their place in practice. I would also emphasize that we should give ways to the actual question. It is frustrating to ask "how can I do X" and only being told "you shouldn't want X". Of course we can present arguments for why we think X is not a good idea, but answering the question should be first and foremost. And we can always have a thorough discussion of whether such an API should exist or not, once someone proposes to add it to the stdlib. On Wed, Feb 3, 2021 at 1:37 PM Wojciech S. Czarnecki <o...@fairbe.org> wrote: > Dnia 2021-02-02, o godz. 22:26:10 > "hey...@gmail.com" <hey....@gmail.com> napisał(a): > > > > So having a “meta/relaxed decoder” usually leads to > > specification/interoperability/security problems down the road > > > I respectfully disagree. Since it's only relaxed with regard to > decoding, > > it follows the robustness principle where you be liberal in what you > accept. > > I disagree with such disagreement in this (security) context. > "Robustness" stated as "accept lousy data" is against security principle > "vet your input thorough". > > > Within a system, the encoding should be explicitly defined, but when > that > > system has to consume base64 data from outside, being liberal actually > > avoids interoperability problems. > > In security context "avoids interoperability problems" may morph to more > accurate "avoids preventing access to our systems by an adversary" - as > adversaries are known to eagerly and clandestinely interoperate with our > software using whatever means we left them to exploit. (Off the hat > example: consuming "liberal" JSON input may allow an attacker to disrupt > data guarded by a simple MAC scheme.) > > TC, > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/20210203133700.36c529f9%40xmint > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHT_dZqVC-bOkPenpiHz%2BtThgXb3s3p14tT%3DrKkb_nBvg%40mail.gmail.com.
