This post assumed that the author of the "runs" commit was not acting maliciously. Has that been established? It's not mentioned in this article.
It has been established that "I didn't do it on purpose" is not enough in some cases. You have to _not do it_ _on purpose_. That "fake it till you make it", in this case, understanding what your code does, is perfectly fine in some contexts, not in others, like this one.
This is systematic for that user. Either the user needs to improve or let go.
The organization needs to learn that good commit messages are a requirement for anything to do with crypto and payment systems.
> NEW POLICY If I don't know you, I don't merge you! Thanks XZ!
LLM agents are cheap and good enough that you can write in eg Lean or whatever. Or at least write it in Rust.
1. A novice who doesn't know how to debug issues.
2. Totally incompetent and copying code from Stack Overflow.
I don't think it's specific to microcontrollers, either, the error from the C compiler is something that a competent programmer would be able to interpret, or at least see it as a signal to get someone more experienced in the domain to learn about.
contrary to the post, this was almost certainly not an issue of compilers throwing errors.
Reduced familarity with C could have played a role, but given the number of C experts that looked at this knowing there was an error and still misidentified the cause I don't think we need to reach for that powerful an explanation.
Confusion of definedness vs value check would make for a fine underhanded C entry. The flaw was not particularly clear from the source... and most common QA procedures could not distinguish a PRNG from TRNG once the error happened.
The article makes the fair point of the size of the change and the complete lack of information in the commit message, which should have set off alarm bells…
Also running python on a microcontroller to do cryptography is fucking insane.
I feel like I should confess to snubbing this (and some other) hardware wallet projects for the fact it used micropython. I think it's hard to draw the line between systems programmer snobbery and good advice... and I feel a little like a cop guilty of stop-and-frisk on the basis of skin color.
Because in general the ideas necessary to produce reliable software aren't well understood or agreed on there is a risk of letting style preferences which are only correlated with good engineering but aren't causative of good engineering get mistaken-- and this can cause errors in both directions, both mistaking stuff as good because it uses the "right" tools, or mistaking something as bad because it doesn't.