chromium: 116.0.5845.179 -> 116.0.5845.187

[j4m3s-s]

https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_11.html

This update contains 1 security fix.

CVEs:
CVE-2023-4863

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[github-actions]

Successfully created backport PR for release-23.05:

• [Backport release-23.05] chromium: 116.0.5845.179 -> 116.0.5845.187 #254747

[delroth]

Note that this might not actually address CVE-2023-4863 since chromium in nixpkgs doesn't use the vendored libwebp, and the fixed libwebp is currently only in staging-next.

See #254798

[emilylange]

After looking a lot into chromium over the past two days, I can confidently say, that chromium (and ungoogled-chromium by proxy) is currently using the vendored version of libwebp.

This is by mistake -- yes.
I am planning to send a patch adding the build flag to use our package soon-ish.

But I am just extremely busy right now.

[delroth]

Could you let me know how you determined this? My grepping of strings from libwebp does not find any matches in chromium, and it's the same method I've used to determine vendoring everywhere else. If it's wrong, that means we potentially have many more false negatives than just chromium!

$ grep -lr "no memory during frame initialization." $(nix path-info -r /nix/store/f4w82dxqh6s21icxmq05kfk9s4hva58j-chromium-117.0.5938.88)
/nix/store/fayvwihc12xywzgv4wnf0cy3gkawvzl6-libwebp-1.3.1/lib/libwebpdecoder.so.3.1.7
/nix/store/fayvwihc12xywzgv4wnf0cy3gkawvzl6-libwebp-1.3.1/lib/libwebp.so.7.1.7

[delroth]

More evidence:

$ nix log /nix/store/0m0ah7634bpd38b98fp7znhcm4brldfh-chromium-unwrapped-117.0.5938.88 | grep third_party/libwebp
[8063/84616] ACTION //third_party/libwebp:gen_libwebp_shim(//build/toolchain/linux/unbundle:default)
[8065/84616] STAMP obj/third_party/libwebp/gen_libwebp_shim.stamp
[8066/84616] STAMP obj/third_party/libwebp/libwebp_shim.stamp
[8067/84616] STAMP obj/third_party/libwebp/libwebp_webp.stamp
[8068/84616] STAMP obj/third_party/libwebp/libwebp.stamp
[31962/84616] ACTION //third_party/libwebp:gen_libwebp_shim(//build/toolchain/linux/unbundle:host)
[31964/84616] STAMP host/obj/third_party/libwebp/gen_libwebp_shim.stamp
[32625/84616] STAMP host/obj/third_party/libwebp/libwebp_shim.stamp
[32626/84616] STAMP host/obj/third_party/libwebp/libwebp_webp.stamp
[32627/84616] STAMP host/obj/third_party/libwebp/libwebp.stamp

No evidence of C++ code in third_party/libwebp getting built.

[emilylange]

Oh.

I should just go to bed.
Way too much right now.

I've meant re2, but was somehow laser-focused on libwebp for some reason.
Sorry for the confusion.

You are very much right.