It is perfectly possible that Google is doing all sorts of Evil Stuff (TM) in the binaries that they ship out. I don't think it's likely, because a fair few people will be examining the packets it sends -- but it is possible.
With Chrome, that isn't possible. It is based on Chromium, but includes non-open source code, and so you cannot immediately build it.
However, in the end, they're just executables. Looking at assembly isn't quite the same as looking at source code, but we could examine the additional components and try to identify any malicious parts. At least in theory -- the work involved would be quite big.
Pretty sure it's actually very hard, I'd assume they use FDO in their builds.
Actually, this sounds like a fairly interesting project to me: Given a tool chain and a source code base, can we prove this was a possible compilation? In the case of deterministic compilers this is trivial, but as you highlight, not all optimizers are.
You wouldn't be able to compile bit-identical releases due to FDO, but otherwise ...
Re-creating bit-identical copies is hard when you _try_ to make it happen for your project, and I can't see any active efforts for that in most OSS projects.
Timestamps in .o/.lib files, use of system libraries, optimization heuristics, exact versions of the entire toolchain, and many more "fun" issues prevent that from happening, usually.
Yes, and your point is? Security audits do mean much, that's why they are done. Open source means a lot as well, it means that if I don't trust a software, I can check it if I want to, rather than accepting what a company is telling me.
There's a reason why cryptographic stuff is almost exclusively open source, it's because security through obscurity doesn't work.
That said, the amount of exploits for open and closed source software is more of less equivalent, but the time to fix is usually shorter for open source code.