There's some work in looking at alternative ways of administering the BCG vaccine (iv injection, inhalation). The IV numbers are pretty promising -- if the monkey numbers hold. I hope that someone, somewhere pushes it into human trials soon.
There's also the nebulous but very nice-sounding "non-specific effect" with it. Who knows.
Interesting, it was my understanding that you don’t actually gain immunity to TB after an infection (as the treatment itself eliminates the bacteria; not your body, mycobacteria stay alive within microphages) so curious what about alternative injection approaches works
We do know that for the lucky ones on which SSRIs do work, it seems to reverse some of the brain structure changes associated with depression -- some abnormally small parts tend to grow thicker. The reversal can be seen at one week after the start of medication use, before one can even tell whether an antidepressant has started working (a commonly-cited duration would be 2 weeks).
Lenore’s approach uses rejection sampling, which translates to needing an uncertain amount of input — a uint128 may or may not be enough.
But there is one related algorithm that doesn’t: https://github.com/apple/swift/pull/39143. This method only requires (output word size + 64) bits, which is really convenient for us since we probably don’t have 2^64 buckets. Same ballpark as (hash >> 64) * n, just with bias correction.
With this method the output value will be very not-scrambled relative to the high bits of the hash. Now whether that’s a problem is… someone else’s question. One can always do some shifts and XORs.
You don’t need to worry about this for mapping hashes to buckets, because a hash has a limited width, whereas unbiased random numbers are based on an unbounded stream of random bits.
In this article they are working with 128 bit hashes so they already have plenty of bits for bias not to be a problem. A single straightforward multiplication is fine.
(1) changing the RSA decrypt function in OpenSSH is all the code hidden in crc64 does: that's the only known behavior, but we don't know what the changed function does besides letting some authentication through, nor do we know if there are other things it does
(2) there's no malicious machine in your LAN exploiting the RSA decrypt to log onto your sshd: nobody has seen one yet, but it doesn't mean there's no such thing.
If you are not using a distro that does dpkg or rpm, or if your machine is not x86-64, you're free from the "code hidden in crc64", the one that targets sshd, CVE-2024-3094. Are there unknown backdoors? Who knows. Do we count the landlock sabotage as a backdoor?
It's hard to deal with unknowns. Assume the worst, maybe, but what even is the worst?
It is unclear what exploiting means. The backdoor is doing _something_ for 0.5s if RSA key exchange happens.
So even a valid login might trigger not yet known side effects. It might just tunnel commands over dns for example (DNS being a well known side effect of ssh anyway).
So "exploiting" might mean as little as "used ssh".
Presumably they wanted this backdoor hidden, so they wouldn't want it doing things that could expose it. I'm under the impression it simply modifies memory when sshd loads the xz library, adding its own hooks and just waiting for the proper login signal. I doubt it "phones home" as this could expose its existence, but we'll have to wait until it is analyzed thoroughly.
The delayed access "embargo" scheme is not that bad… if you are not chasing the latest stuff in the field. It works well enough for casual Wikipedia editing and junior researchers.
I don’t deal with the ASA much, but I do use the PNAS a lot — their HTML paper layout isn’t bad and they do maintain a nice archive. The National Academy of Science deserves some money for good web work, I just don’t know whether it’s just for them to take it from the embargo.
Also, how much marginal utility does "the public" gain when you reduce or remove an embargo?
Macfuse itself has been closed source for a long time. Whether their EULA is compatible with the LGPL though, I don’t know. (Also, the old question: are APIs copyrightable?)
But do they bundle libfuse as a dylib? If they do, they’re probably in the right.
And API copyright aside, how would one prove it’s only API compatible and not using the implementation as well without also open sourcing their implementation?
It would almost be better to be similar but not the same. Then everyone else can just do subtle ifdef changes to their fuse code.
India is the world’s bigger producer of turmeric and many other spices after all. Won’t be surprising that these batches originated in India and were made using adulterated rhizomes.
There's also the nebulous but very nice-sounding "non-specific effect" with it. Who knows.