Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When random.bytes() runs but doesn't work

insider.btcpp.dev

Post reply on HN
Print view View original

11–20 of 63 posts

Re: When random.bytes() runs but doesn't work

#11

Post by nullc »

nullc wrote: post #9

This writeup isn't very good and misses/misunderstands the programming error that leads to the flaw. I'm commenting because I think it's important to understand the issue. The article would have you think that the change in question was a tiny change to a flag to make it compile, but in reality the commit in question is a 1533 line addition of the entire RNG infrastructure. The fundamental cause is a mixup between a…

Aside, I'm somewhat surprised that MISRA (as of 2012 at least) doesn't have a directive related to definedness vs value errors.

Re: When random.bytes() runs but doesn't work

#12

Post by karamanolev »

anonymousiam wrote: post #2

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.

Per the article, not my opinion.

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.

Re: When random.bytes() runs but doesn't work

#14

Post by jonathanlydall »

systemsweird wrote: post #8

Very good writeup and an astonishing level of negligence for an extremely security critical piece of code. The losses are going to surpass 100 million, these guys should be thrown in jail.

This does not seem to be a good write up at all, see nullc’s explanation in this discussion of (what seems to me) the actual root cause whereas this article spent a lot of words making the argument that bad commit messages must mean bad code, later using the assertion to try “prove” what the technical problem was.

I agree that a bad commit message combined with a big commit is a huge smell, but as it’s just metadata for the code and not the code itself, it is not in itself evidence in any form.

That being said, probably okay after explaining the technical code issues for the author add a couple of a sentences about how all this was was part of 1000s of a lines of code changed in commits with useless messages which demonstrates generally bad code hygiene.

Re: When random.bytes() runs but doesn't work

#15

Post by smithcoin »

jonathanlydall wrote: post #14
systemsweird wrote: post #8

Very good writeup and an astonishing level of negligence for an extremely security critical piece of code. The losses are going to surpass 100 million, these guys should be thrown in jail.

This does not seem to be a good write up at all, see nullc’s explanation in this discussion of (what seems to me) the actual root cause whereas this article spent a lot of words making the argument that bad commit messages must mean bad code, later using the assertion to try “prove” what the technical problem was. I agree that a bad commit message combined with a big commit is a huge smell, but as it’s just metadata…

I think what is the author is getting at is that if you are cavalier in your commit messages when the stakes are low, chances are you aren’t taking writing code that handles money seriously. Made me think of some merges I could have taken more seriously.

Re: When random.bytes() runs but doesn't work

#16

Post by smithcoin »

nullc wrote: post #9

This writeup isn't very good and misses/misunderstands the programming error that leads to the flaw. I'm commenting because I think it's important to understand the issue. The article would have you think that the change in question was a tiny change to a flag to make it compile, but in reality the commit in question is a 1533 line addition of the entire RNG infrastructure. The fundamental cause is a mixup between a…

Have you found a write up you’d recommend on how the threat actors actually exploited the vulnerabilities?

Re: When random.bytes() runs but doesn't work

#17

Post by nonfamous »

From the Twitter advisory on the issue being referenced here [1]:

>>> To every other developer: we believe this is a sober reality of the new AI paradigm. AI-assisted code review can now find latent bugs at a speed that is outpacing even the industry’s most seasoned experts. If your firmware is open-source or has ever been public, assume it's already being read by attackers and defenders alike.

Kinda turns the “many eyes” principle of OSS on its head, eh?

[1] https://x.com/nvk/status/2083216713693151552?s=61

Re: When random.bytes() runs but doesn't work

#18

Post by RustyRussell »

nullc wrote: post #11
nullc wrote: post #9

This writeup isn't very good and misses/misunderstands the programming error that leads to the flaw. I'm commenting because I think it's important to understand the issue. The article would have you think that the change in question was a tiny change to a flag to make it compile, but in reality the commit in question is a 1533 line addition of the entire RNG infrastructure. The fundamental cause is a mixup between a…

Aside, I'm somewhat surprised that MISRA (as of 2012 at least) doesn't have a directive related to definedness vs value errors.

Always use -Wundef. For CCAN all config vars use #if and we lint for ifdefs of them, because you have to pick a side here, and sometimes using HAVE_X in C code is useful, so I prefer always-defined.

Re: When random.bytes() runs but doesn't work

#19

Post by silvestrov »

anonymousiam wrote: post #2

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.

When looking through all the other commits the user has made: they all lack a good commit message.

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.

Re: When random.bytes() runs but doesn't work

#20

Post by PunchyHamster »

> The commit message is 235 characters, and the commit changes 15 lines of code. That’s a ratio of 235/15 = ~16.

the commit message is not 235 character long, the commit message is this

> splice-script: Test for msat chan balances > splice-script: Round channel balances down

author mistakes commit message for PR which doesn't get persisted into code's history and don't even contain the ID of bug being fixed.

So yeah it is better but nothing to actually brag about

Post reply on HN