4 ms·

The same could be said for any binary releases, from open source code or not (e.g. Firefox). If you don't trust Google's binary releases then build your own Chr

The same could be said for any binary releases, from open source code or not (e.g. Firefox). If you don't trust Google's binary releases then build your own Chromium from audited sources.

mcpherrinm 14y ago
Yes, trusting binaries is a little scary. But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. 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.
- tonfa 14y ago
  > But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. Pretty sure it's actually very hard, I'd assume they use FDO in their builds.
  - mcpherrinm 14y ago
    That's true. I know profile-guided-optimization is used for Windows builds; unsure on other platforms. 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.
    - LukeShu 14y ago
      I'm fairly certain that PGO is used for all of the official binaries. I do know that Arch Linux's package (which is from source, not official binaries) is compiled with PGO, so the support is definitely there.
      - Hello71 14y ago
        The scripts used to automate PGO are in the official repository.
- DannyBee 14y ago
  All non-open source code in chrome should be in plugins (or otherwise separate DLL's), not chrome's main binary. If you know of a case where this isn't true, please let me know. You wouldn't be able to compile bit-identical releases due to FDO, but otherwise ...
- groby_b 14y ago
  Theoretically, you should be able to compile a bit-identical release. Practically, you won't. (Or at least, I'd be very surprised) 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.

The same could be said for any binary releases, from open source code or not (e.g. Firefox). If you don't trust Google's binary releases then build your own Chromium from audited sources.

mcpherrinm 14y ago

Yes, trusting binaries is a little scary. But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. 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.

tonfa 14y ago
> But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. Pretty sure it's actually very hard, I'd assume they use FDO in their builds.
- mcpherrinm 14y ago
  That's true. I know profile-guided-optimization is used for Windows builds; unsure on other platforms. 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.
  - LukeShu 14y ago
    I'm fairly certain that PGO is used for all of the official binaries. I do know that Arch Linux's package (which is from source, not official binaries) is compiled with PGO, so the support is definitely there.
    - Hello71 14y ago
      The scripts used to automate PGO are in the official repository.
DannyBee 14y ago
All non-open source code in chrome should be in plugins (or otherwise separate DLL's), not chrome's main binary. If you know of a case where this isn't true, please let me know. You wouldn't be able to compile bit-identical releases due to FDO, but otherwise ...
groby_b 14y ago
Theoretically, you should be able to compile a bit-identical release. Practically, you won't. (Or at least, I'd be very surprised) 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.