It would be nice if the passwd crypt functions didn't have timing dependence on password length. Then there'd never need to be hacky workarounds like what musl did, and various tricks to avoid exposing whether users exist on systems.

No idea if it's likely to happen though.

Probably because mitre take days to weeks to give out CVE numbers (if ever). Just get the fix out there.

No. The password gets sent to the server. That said, I still enable passwords on servers, but don't ever share passwords between trust domains.

Dropbear added the 100 character password limit in 2019.77, so earlier versions might be susceptible.

Nope, they are OK.

59 seconds will still have second alignment. Maybe it needs to be prime milliseconds or microseconds.

But seconds are 60X higher frequency than minutes. This is almost 6 octaves higher. The grid will low-pass-filter that out much better than the minute period. (You can see that trend in the diagrams given in the article: the amplitudes all get lower with decreasing period to the left, where the 60 second blip is a an outlier.)

Secondly, the amplitude drops. Events that were concentrated on the xx:xx:00 times are now distributed into xx:xx:xx times. If the overall number of events is the same, each :xx time slot now receives 1/60th of the events that were concentrated on the :00 time. If power decibels are relevant here (20 log 10 x), that's a 35 dB reduction in amplitude of the driving signal.

35 dB less amplitude, shifted to a 6 octave higher frequency that the grid doesn't react to very well can be expected to basically make the problem vanish.

This is much like the situation of soldiers avoiding rythmic marching when crossing a bridge to randomize their footstrikes.

It depends on a lot of factors, but even second granularity gives you a 60x reduction in the thundering herd. Whether more is needed or even possible often depends on the specific problem domain. For example, if your task takes 20ms, us granularity doesn’t help. Indeed it makes it worse if you’re using randomization because there’s a lot more microseconds than seconds so you can end up with a lot of work that ends up in practice still getting scheduled together due to other delays.

You want your jitter to be significantly >> than the time your task takes as otherwise you get non intuitive degradation that can reintroduce the problem you’re trying to solve. It’s a balancing act picking the jitter that drops off the thundering herd enough and one that is still greater than the time your work takes.

I think you should re-read the post you're responding to. It said 59.XXX seconds, and given the reasoning immediately after that, it's clear that XXX is intended to be a randomly chosen number of microseconds.

That was edited in later

Does this mean that their WebTrust Seal auditor (BDO Malaysia) didn't do a very good job? https://www.cpacanada.ca/api/getPDFWebTrust?attachmentId=3d8...

Fuzzing doesn't tend to catch overflow cases since operations aren't repeated enough times. I wonder if fuzz engines could add a "counter detection" pass that reruns inputs that are seen to increment values. Maybe that's already been tried by someone.

dmesg

Maybe you could report it as a normal bug report, by hand?

Unless the field of software development somehow totally stagnates, I'm confident that at some point I will move to a different hosting service, as github goes the way of sourceforge, travis-ci, and myspace. So my personal domain will continue to be relevant (it's lasted fine 23 years).

Maybe at that point it won't be using git either, or maybe it will - who knows.

Mine has lasted over 25 at this point, but one day I will die, my domain name will lapse because what I do as a career might as well be witchcraft to anyone in my family and then my modules will be lost forever. Sucks any way you cut it. Hopefully someone who found my modules useful will fork whatever they find and keep them going.