Live data from Hacker News

setBigTimeout

evanhahn.com

121–129 of 129 posts

Re: setBigTimeout

#121

Earlier quoted context omitted.

A scenario where an attacker can control a timeout where having the callback run sooner than one minute later would lead to security failures, but having it set to run days later is perfectly fine and so no upper bound check is required seems… quite a constructed edge case. The problem here is having an attacker control a security sensitive timer in the first place.

I would imagine the intent behind this would be that the attacker has indirect control over the timeout. E.g. a check password input which delays you in between attempts doubling the length of time you have to wait in between each failed attempt. With this bug in place, the attacker would simply wait all the timeouts until the timeout exceeded 25 days at which point they could brute force the password check back to b…

A login back off should be capped to a number of hours rather than be allowed to grow to a month though. I also have a hard time seeing this implemented as setTimeouts for every failed login attempt instead of storing a last login attempt time and counter in a user database with a time comparison when login is called.

It’s definitely suboptimal though, even if it is documented.

Re: setBigTimeout

#122
post #118

Awesome! Already have a project I can use this on, thanks. As a side note, why do you use this weird non-Github, non-Gitlab, non-Bitbucket sketchy looking git host? I can see the code obviously, but it makes me worry about supply chain security.

sourcehut isn’t weird at all. It’s made by Drew Devault who is mostly well-respected in the hacker community, and it’s made exactly to be an alternative to BigCo-owned source hosts like GitHub, Gitlab and Bitbucket.

Drew isn't well-respected, he's been far too antagonistic to far too many people over the years for that.

Latest news is that he authored/published a controversial character assassination on Richard Stallman while trying and failing to stay anonymous. Then some further digging after this unmasking found he's into pedophilic anime. Sitting on his computer uploading drawings of scantily-clad children to NSFW subreddits.

No-one with any decency can respect that behavior, it's disgusting.

Re: setBigTimeout

#123

setTimeout is stranger than you think. We recently had a failed unit test because setTimeout(fn, 1000) triggered at 999ms. That test had ran more than a hundred times before just fine. Till one day it didn't.

Why does your unit test need to wait one second? Or are you controlling the system time, but it still had that error?

How else would you test if something happens after 1 second or not?

Re: setBigTimeout

#124

setTimeout is stranger than you think. We recently had a failed unit test because setTimeout(fn, 1000) triggered at 999ms. That test had ran more than a hundred times before just fine. Till one day it didn't.

I don't think there is any guarantee that setTimeout will run at exactly 1000. Though didn't expect it to run earlier, it definitely could run later.

Same. I expected it could take a few ms longer. But less? Apparently that's a thing.

Re: setBigTimeout

#125
post #104

This makes me love having Go handy. I find working with signals and time based events so much nicer than other languages I use. This is fun, though. JS is a bucket of weird little details like this.

Go timers do have weird little details, in fact one little detail changed recently in 1.23 and broke my code. A third party dependency selects on sending to a channel and time.After(0); before 1.23, due to timer scheduling delay, the first case would always win if the channel has capacity to receive, but since 1.23 the timer scheduling delay is gone and the “timeout” wins half the time. The change is documented at ht…

Oh, interesting. That’s legitimately annoying. I have a huge scheduling component in an application that could be (probably is) impacted by this, so thanks for the heads up!

Re: setBigTimeout

#126

Earlier quoted context omitted.

Off the top of my head, a cron scheduler for a server that reads from a database and sets a timeout upon boot. Every time the server is reboot the timeouts are reinitialized (fail safe in case of downtime). If upon boot there’s a timeout > 25 days it’ll get executed immediately which is not the behavior you want.

Why would you do that in JS rather than just using cron for it?

It can be quicker since you are in the environment already and you are sure that they will activate only when your program is running

Re: setBigTimeout

#127

Earlier quoted context omitted.

Why does your unit test need to wait one second? Or are you controlling the system time, but it still had that error?

How else would you test if something happens after 1 second or not?

By mocking the system time and manually progressing it a set amount of time. Otherwise your tests actually take seconds rather than a few milliseconds.

Not a great example, but here is something I did recently that tests time based state (thousands of seconds) but the suite passes in tens of milliseconds.

It also uses a random number generator with a deterministic mode to allow random behaviour in production, but deterministic results in tests (unrelated but also handy)

https://github.com/steveadams/minesweeper-store/blob/main/sr...

Some writing about the repo in case you’re curious: https://steve-adams.me/building-minesweeper-with-xstate-stor...

Re: setBigTimeout

#128
post #107

In response to this, I read the spec of setTimeout, bu I couldn't find the part where implementations may have an upper bound. Can someone more familiär with the specs point me in the right direction?

Here’s a deep dive in 6 minutes https://youtu.be/boD0ReK62FI?si=jSXuQn0DHn3riJgd Just JS being JS: setTimeout(()=>{}, Infinity) executes immediately

Thanks, but I'm looking for the specification of this behaviour.

Re: setBigTimeout

#129
post #4

Got hit with this one a few months ago.

Just out of curiosity, what was the use case for a really long timeout? Feels like most if not all long timeouts would be best served with some sort of "job" you could persist, rather than leaving it in the event queue.

Nice to have bit of client side auth code. A timer is set to update your auth status when the refresh token is scheduled to expired. I've left tabs open for 30+ days.
Post reply on HN