Comment by eru
17 hours ago
Also: writing this stuff in C just begs for bugs.
LLM agents are cheap and good enough that you can write in eg Lean or whatever. Or at least write it in Rust.
17 hours ago
Also: writing this stuff in C just begs for bugs.
LLM agents are cheap and good enough that you can write in eg Lean or whatever. Or at least write it in Rust.
The bug has been up since before the LLM shift.
I get the feeling that the bugs found in this instance can be more directly attributed to the author having zero experience operating a microcontroller
Honestly, I'm going to be a bit harsher: I think they're either:
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.
> the error from the C compiler is something that a competent programmer would be able to interpret,
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.
1 reply →
C isn't the problem here. one might argue that the combination of micro python and C and the person writing it having no understanding of how either one works is the problem.
Also running python on a microcontroller to do cryptography is fucking insane.
> 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.