Feedback and bug reports (exception: security) should be public and users should be able to vote. Apple then could prioritize much better.
Also, take a look at their user forums: They are full of bug reports with hundreds of users having the same problems - and nothing happens. I really wish they would react much better with official acknowledgments, references to open bugs, workarounds, etc. It is depressing how much collective time is wasted.
The map reminds me of this infamous plot [1]. Look at how many more points there are in North Carolina, New Jersey, and Massachusetts than surrounding states. Naively we would conclude that these states have way more PFAS contamination. But maybe they are just considerably better about testing for and reporting it?
I think AMD needs to take a page from Nvidia and really get their software together. The CPU and GPU libraries are a mess. There are multiple versions of libraries where in some cases both are maintained and it's not clear which to use, and in others, one is dead but may perform better than the new one. Intel and Nvidia let you download a single package for all scientific computing.
IMHO it's worth mentioning that this discussion is about Spectre variant 1 (as is the original article). I.e. we should not write "Spectre" when we talk about a specific Spectre variant.
I'm mentioning this because (at least to my understanding) in Spectre variant 2 the entire address space of the victim process can be used to find the "gadget" i.e. an usable target for the indirect branch. This means that making only your input validation code "spectre-free" is not good enough for variant 2. (This is why e.g. OpenSSH recently started using the (Spectre variant 2!) retpoline compiler flags of GCC/LLVM if available. See this thread for details: https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-Fe...)
True, but variant 2 isn't as gloomy as it sounds because there's 2 major challenges with it. The first is you need detailed knowledge of the binary you're targeting as well as it's memory layout. ASLR makes that challenging, to say the least. You then also need a side channel of some sort to observe the effects, such as shared memory.
There are better cryptographic hash functions (e.g. Blake2) than SHA1 that are even faster. Check out the "results" slide of this slide deck for the cycles per byte table: https://blake2.net/acns/slides.html
"When performing Diffie-Hellman Group Exchange, sshd(8)
first estimates the size of the modulus required to
produce enough Diffie-Hellman output to sufficiently
key the selected symmetric cipher. sshd(8) then randomly
selects a modulus from /etc/ssh/moduli that best meets
the size requirement."
The problem is
a) OS distributions ship pre-computed moduli in the /etc/ssh/moduli file. I.e. most users don't change these moduli. This facilitates pre-computation attacks.
b) These moduli are often too short (<2048 bit).
You can create your own moduli with ssh-keygen (see the "MODULI GENERATION" section in the ssh-keygen manpage).
FWIW: Here's my open bug for RHEL7 where I try to convince Red Hat to improve the situation (including more details and references):
I know the article explicitly and consistently says 'encryption' everywhere. I simply cannot fathom that they were encrypting instead of hashing. While I suppose it's possible that the SHA-1 versions were encrypted, I refuse to believe that the dropbox security team would transition from that to bcrypt 2-directional encryption over bcrypt 1-directional hashing. With that assumption I find it safe to say the tech journalist is being inaccurate.
