2

From the: Abusing SHA-1 collisions for Chromium updates

https://news.ycombinator.com/item?id=20114809

https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/browsers/chromium/update.nix#L96

Why would Chrome return non-deterministic bytes for a versioned release?

(too long code to paste it here! but fixme.)

2
  • I'm not sure, but I'd say it's because of "performance",this will limit the bandwidth used and increase speed... Jun 7 '19 at 13:39
  • 3
    Hi niving, can you add the relevant bits for the external links to the question so that it is more self-contained? This not only makes it easier on users who might want to answer but also improves the discoverability of the question via search.
    – Xander
    Jun 7 '19 at 15:44
1

Chrome is not returning non-deterministic bytes for a versioned release.

aszlig wanted to update a nix manifest to check from the network if there were updates. However, there's no such function in Nix. Why not? Because you're not really supposed to do stuff like that in the Nix paradigm which is all about determinism.

Nix only allows you to download if you already know the contents of the file in advance (in the form of its hash).

He made such a package that tries to download the Chrome update and results in the boolean information about whether the update was available. But the result needs to have the same hash in both cases. That's where a hash collision comes in handy.

This build script uses a couple of well-known PDF files that both have the same SHA1 hash. If the update exists, it gives PDF 1, otherwise it gives PDF 2.

The update script then depends on that hack package. It "installs" that package, and then checks whether it actually contains PDF 1 or PDF 2, and now it knows whether the Chrome update was available or not.

(based on mbrock and grhmc answers)

Not the answer you're looking for? Browse other questions tagged or ask your own question.