4 ms·

I once reported a bug to a barcode decoding library, reporting that it crashed when the barcode contained a zero byte. They responded that they wouldn't fix it

by billpg 2y ago

I once reported a bug to a barcode decoding library, reporting that it crashed when the barcode contained a zero byte. They responded that they wouldn't fix it because barcodes aren't supposed to contain zero bytes. "But it crashed. That's bad. I can't stop people scanning bad barcodes."

TacticalCoder 2y ago
> 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.
unnouinceput 2y ago
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook
- lazide 2y ago
  Combined with the all to human reflex of engineers to insist that it isn’t their implementation/design that is wrong, it is reality which is wrong. Clearly. Because if we just didn’t do that, then it would all work. In particular, see folks talking about Self Driving hah.
alex_suzuki 2y ago
Do you by chance remember which library, and which barcode symbology? (barcode library developer here :-)
- billpg 2y ago
  I do remember it was a large 2D barcode. Like QR but with a square in the middle. (AZTEC?) I was trying random barcodes I had lying around to test my own component. The one with the zero byte happened to be a large one they had added to my passport when I visited the USA. It had "US-VISIT" printed next to it in big letters. The device was a rugged industrial handheld device with a screen and a camera, designed for mailrooms and warehouses. This was around 20 years ago and I remember the OS (including the barcode component) was completely bespoke and it ran without any process protections. This meant that the barcode would crash the whole device and you had to perform a hard reset.
  - alex_suzuki 2y ago
    Square in the middle sure sounds like Aztec. It‘s used alot for airline boarding passes. What‘s more common with zero bytes instead of crashes is truncation… some part of the code assumed the zero byte terminates a string. Thanks for replying!

by billpg 2y ago

TacticalCoder 2y ago

> 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.

unnouinceput 2y ago

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook

lazide 2y ago
Combined with the all to human reflex of engineers to insist that it isn’t their implementation/design that is wrong, it is reality which is wrong. Clearly. Because if we just didn’t do that, then it would all work. In particular, see folks talking about Self Driving hah.

alex_suzuki 2y ago

Do you by chance remember which library, and which barcode symbology? (barcode library developer here :-)

billpg 2y ago
I do remember it was a large 2D barcode. Like QR but with a square in the middle. (AZTEC?) I was trying random barcodes I had lying around to test my own component. The one with the zero byte happened to be a large one they had added to my passport when I visited the USA. It had "US-VISIT" printed next to it in big letters. The device was a rugged industrial handheld device with a screen and a camera, designed for mailrooms and warehouses. This was around 20 years ago and I remember the OS (including the barcode component) was completely bespoke and it ran without any process protections. This meant that the barcode would crash the whole device and you had to perform a hard reset.
- alex_suzuki 2y ago
  Square in the middle sure sounds like Aztec. It‘s used alot for airline boarding passes. What‘s more common with zero bytes instead of crashes is truncation… some part of the code assumed the zero byte terminates a string. Thanks for replying!