4 ms·

> They responded that they wouldn't fix it because barcodes aren't supposed to contain zero bytes. Sad. What a poor understanding of our field. The number one

> They responded that they wouldn't fix it because barcodes aren't supposed to contain zero bytes. Sad. What a poor understanding of our field. The number one rule of them all is: "Never trust (user) input". A slightly more powerful variation being: "assume all input is malicious until proven otherwise". I mean: on one hand there are people who fuzz, who test, who think about edge cases, who think about security, who think about uptime, etc. And OTOH you have people saying "such input shouldn't happen". It's just really pathetic.

adolph 2y ago
I think a difference between an application and a library (or module, etc) is that it is ok for the latter to expect sanitized input and be wrapped in try/catch blocks. The world is less finite than code and a module might be deployed in a variety of contexts which might make some checks undesirable. In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP. https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
- 0cf8612b2e1e 2y ago
  Malformed data is a fact of life. A parser should gracefully fail when this eventuality happens.
- bitexploder 2y ago
  The library also has the best chance to fix and prevent security issues systemically. I have played this game for a while now. Library engineers often want to pass the buck onto users of their tools. That is not good developer or user experience. Also crashing is the opposite of robust.
- david422 2y ago
  If that's the case, the library should also have another function or method that can validate the barcode if the application should so choose. The library is the barcode expert, the app is the business logic expert. Expecting every app to now become barcode experts doesn't make sense. Also, that law gets quoted, and IMO is a rather large design mistake.

adolph 2y ago

I think a difference between an application and a library (or module, etc) is that it is ok for the latter to expect sanitized input and be wrapped in try/catch blocks. The world is less finite than code and a module might be deployed in a variety of contexts which might make some checks undesirable. In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP. https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle

0cf8612b2e1e 2y ago
Malformed data is a fact of life. A parser should gracefully fail when this eventuality happens.
bitexploder 2y ago
The library also has the best chance to fix and prevent security issues systemically. I have played this game for a while now. Library engineers often want to pass the buck onto users of their tools. That is not good developer or user experience. Also crashing is the opposite of robust.
david422 2y ago
If that's the case, the library should also have another function or method that can validate the barcode if the application should so choose. The library is the barcode expert, the app is the business logic expert. Expecting every app to now become barcode experts doesn't make sense. Also, that law gets quoted, and IMO is a rather large design mistake.