I thought this would be true at the beginning, and was trying to be generous, as anyone can have a bug. But the software craftsmanship was incompetent on all levels: * Starting from the management decision to get off open-source for the firmware, * Using MicroPython wrapping to facilitate shitcoinery, which raised the complexity and added the faulty library to the stack, * Falling back on a critical path, instead of throwing an error and breaking, * And what has got to be encryption test cases so bad that they're going to end up in computer science textbooks under "What not to do." I've been in software development since 1998 and I have **never ever** seen such poor software craftsmanship. Not industry-standard practice and arguably criminally negligible. If we did this in automotive, bioinformatics, or heavy industry, they would sue us into the ground and arrest the CEO.

Replies (3)

You have a beautiful mind. I looked over the code and the purported fixes. It is horrible. And it's defended by a certain arrogant dickhole with "you don't even understand the code" and "security is the hard part." That is the mark of a dumbshit who can't defend the spaghetti he made, calls himself a genius for being able to understand it, and then he attacks the critic. Good code is legible. This code is not. It has the illusion of legibility because the top-level code is simple, but all the heavy lifting underneath is a linker's nightmare. Speaking of which, this should have been obvious if you inspected the linker's call-tree output, which I suspect was disabled.
I agree, and have reached a similar conclusion. When I posted this, I hadn’t seen any of the information about the code or additional context we have now. I am not a software developer and haven’t spent enough time studying code to be anywhere near an expert. So it would have been pretty half-cocked of me to making judgements about anything software related. However, based on the most current information, the issue appears to be one of incompetence and negligence.