It seems like in the case of Meltdown and Spectre, FOSS may have /everything/ to do with security. FOSS with the addendum that you don't execute arbitrary javascript, anyway.

In a world where personal computers only ran code the user could safely trust, these exploits would only be full attack vectors when applied to multi-tenant computing environments.

I'm not arguing that FOSS systems are inherently more secure than closed systems, but when it comes to exploits that require arbitrary code execution to be effective, Stallman really was/is right. Between a NoScript browser extension and a system whose source code is entirely available to you, you've basically got Meltdown/Spectre immunity.

As much as I would love to believe that I personally can sanely inspect all the code I run - I can't. One day I run apt-get install git and I have to trust all code that is being pulled to my machine (and there is a lot of code there) simply because my lifespan is probably shorter then time required to audit all the code in git dependencies (ssl, crt, kernel, etc). So given I can't possibly audit everything, then I need to trust, and if I need to trust, then being FOSS might make me feel a bit more sure about safety of the code, but in reality it might not even make such a difference - apt-get pulls-in binaries, who knows what/how/where this binaries are made ... trust chain is simply not there.

I personally trust FOSS software more not to do dumb things (like, hopefully my password manager doesn't report all my passwords to NSA), but simply being FOSS doesn't make it any more secure :)

> who knows what/how/where this binaries are made

Reproducible builds (https://reproducible-builds.org/) is an initiative to fix that part of the problem. With reproducible builds, a third party with the same source code and compiler will get an identical binary, so we can have independent entities certifying that the code you download with apt-get was built from the corresponding source code.

RISC V is certainly not vulnerable to Spectere as all the the real-world chips are in-order execution, meaning post-branch instruction never happen until after the branch is decided.

Out of order variants are still in the design stage, so they may come up with a way to isolate or invalidate speculation effects on branch misprediction.

OSS makes vulnerabilities easier to discover, but if the project isn't well known they may still easily go unnoticed.

> Being free (or open) source have nothing to do with security

My Windows 10 machine got the Meltdown patch yesterday, in an out-of-band, undelayable update. Then it restarted itself during the night and this morning it's secure. My Ubuntu laptop is still unpatched and I'm not sure when the 4.15 upgrade will come to 16.04.

Ubuntu is probably going to be updated before January, 9th (https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...)