[dnr]

That's wrong. The google-chrome packages in nixpkgs are "built" by downloading the official releases (in .deb format I think) and massaging them a little. It takes a few seconds.

When the zero-days came out, I just updated the upstream-info.json file in my local nixpkgs checkout (look at previous chrome version bump commits for how to do it) and rebuilt my system. I didn't have to wait for any PRs or merges or CI/hydra. Granted, it requires a little nix knowledge, but if you've been running nixos you can probably figure out how to do it in a few minutes.

[hollerith]

For anyone reading along, if you visit https://www.google.com/chrome/ from a Linux box, then click the big blue "Download" button, you are offered the choice of a .deb or an .rpm. I take it that that is what parent means by "the official releases".

>massaging them a little. It takes a few seconds.

Interesting and surprising. When I run ldd on my Chrome binary (which comes straight from Google, not my distro), it lists 101 dynamically-linked libraries. I believe that that means that the binary contains references (i.e., file names) to those 101 libraries. Does the massaging process just replace those references (file names) with the appropriate names beginning with "/nix/store/"? I.e., does the massaging process edit the binary?

(If so, I'm a little surprised, what with how paranoid Google is, that Chrome doesn't refuse to start because the binary has a different checksum!)

[kaba0]

https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...

I believe this is the package you are talking about. The significant part is basically bash, so it should be readable without nix knowledge as well. And yeah it basically creates both a wrapper for setting some env variables, but it also replaces some dynamic lib locations with patchelf. So apparently it does startup with a different checksum/validation happens at another level.

[dnr]

Yes, exactly: https://github.com/NixOS/patchelf

It's a key part of how nix works.