jiebi/CodeConvo huggingface dataset:
Filing this issue to track related actions in nixpkgs. Feel free to send questions my way and/or contribute via comments in this issue! A buffer overflow in which allows a malicious actor to potentially get code execution in software that displays a specially crafted image file. This impacts pretty much all web browsers, as well as other software which might process or display untrusted images (image editing software, email clients, chat clients, social media clients, etc.). Chrome has rated this vulnerability as critical severity and has indicated that they have evidence some actors are already exploiting it in the wild. This vulnerability was very shortly referred to as CVE-2023-5129, but that second CVE for the same vulnerability has since been withdrawn. Firefox and Chromium are not vulnerable anymore as of 2023-09-16 in and . Direct dependents of the system are also not vulnerable anymore. Some applications bundle their own version of libwebp instead of using the system version (including some other web browsers in nixpkgs: Brave, Tor Browser, etc.). Each of these need to be updated separately by nixpkgs maintainers. See below for a list of all the known applications that need an update and their status. Review/merge any nixpkgs PR that you see pending in the task list below. Help figure out a course of action for . Report your findings and suggested course of action in a comment here, and I'll update the sheet and the task list below. If you have an idea of how to fix/address the vulnerability in any of the packages listed in the task list below, don't hesitate to post a comment here and send pull requests! Feel free to cc me on PRs so I can make sure they're tracked and they don't get lost.[x] libwebp is updated in staging-next (unstable: , 23.05: ) [x] This will make it to master via - said likely this weekend. [x] We need to merge staging-23.05 to release-23.05. That should also finish this week: [x] electron is also vulnerable. Upstream is making new releases on all their supported branches to include the patch. [x] electron 26 bumped in master (). [x] electron 25 bumped in master (). [x] electron 24 bumped in master ().
[x] electron 22 bumped in master (). [x] electron 26 bumped in 23.05 (). [x] electron 25 bumped in 23.05 (). [x] electron 24 bumped in 23.05 (). [x] electron 22 bumped in 23.05 (). [ ] We should figure out what else might be vendoring libwebp. Not sure if there's tooling for this? List of derivations to investigate further and possibly patch: [x] High risk stuff (mail clients, IM clients, web browsers) [x] armcord [x] caprine-bin (, ) [x] discord (, ) [x] Darwin version: / [x] fluffychat () [x] gitter (, ) [x] mailspring [x] mattermost-desktop ( / ) [x] mautrix-whatsapp ( / 23.05 ) [x] microsoft-edge ( / ) [x] mullvad-browser ( / ) [x] palemoon-bin (, ) [x] rocketchat-desktop ( / ) [x] signal-desktop (, ) [x] signal-desktop-beta ( / ) [x] slack ( / ) [x] threema-desktop (embedded electron not used) [x] tor-browser-bundle-bin ( / ) [x] tutanota-desktop ( / ) [ ] Libs that other stuff might depend on [x] flutter [x] libcef ( / ) [x] opencv ( / ) [x] qt5.qtimageformats ( / ) [ ] qtwebengine (darwin only, maybe?) [x] smooth ( / ) [x] darktable () [x] golden-cheetah-bin: ships a vulnerable prebuilt libwebp (cc: [ ] koreader: ships a vulnerable prebuilt libwebp (cc: [x] libreoffice () [ ] localsend: ships a vulnerable prebuilt libwebp (cc: [ ] obs-studio () [ ] rigsofrods-bin (ships a vulnerable prebuilt libwebp (cc: [x] Anything Rust that depends (transitively or not) on libwebp-sys2 < v0.1.8 libwebp-sys2 might silently decide to build its vendored version, if it can't find system libwebp or if the crate feature is enabled.
[x] () [x] catppuccin-catwalk () [x] Anything Rust that depends (transitively or not) on libwebp-sys < v0.9.3 Linking against system webp is intentionally not supported: [x] oculante [ ] .NET software that uses SkiaSharp. Upstream has yet to release a fixed version. () [ ] avalonia-ilspy [ ] BeatSaberModManager [ ] denaro [ ] galaxy-buds-client [ ] jellyfin [ ] mission-planner [ ] mqttmultimeter [ ] opentracker [ ] openutau [ ] ryujinx [ ] scarab [ ] wasabiwallet [ ] Go software linking with (, ) - broken down per vulnerable lib [ ] (unmaintained, likely never getting patched - action should be getting upstream to migrate away) [x] hydron ( / ) [x] mautrix-whatsapp () [ ] () [ ] hugo [ ] Godot related derivations: these should be unvendored (capability already exists in the build system). [ ] godot4 [ ] godot3 [ ] godot3-server [ ] godot3-headless [ ] godot3-export-templates Built using Godot [ ] lorien [ ] oh-my-git [ ] Electron apps where we ship upstream binaries instead of using nixpkgs electron Best course of action: upstream should update to electron = 26.2.1, = 25.8.1, = 24.8.3, or = 22.3.24 and tag a new release [ ] atom [ ] hakuneko [ ] hyper [ ] indigenous-desktop [ ] joplin-desktop [ ] keeweb (unmaintained, mark as insecure?) [ ] keybase-gui [ ] insomnia [ ] mullvad-vpn [ ] simplenoteFor derivations that vendor a vulnerable libwebp, priority list of preferred action to take: De-vendor libwebp and use the version from nixpkgs. (Difficult/impossible for binary provenance derivations.) Update to a new version from upstream that has a more recent libwebp patched for the vulnerability (TODO: how to check?) Mark as at some point if upstream can't be convinced to make a new release.
List of all software in nixpkgs known to contain libwebp:
is now out
i think one way you could check for vendored webp is with nix-locate, searching for , for example darktable might be vulnerable : possibly also koreader the full output
Thanks, that's indeed useful! I think the most common case though would be bundling the code and linking statically with the lib, which wouldn't necessarily be found by this - but maybe I'm just too pessimistic :) EDIT: the ones you found to the tracking in the issue's first comment so we don't lose track of it.
darktable: links with libwebp, the is an internal plugin and is not a vendored version.
koreader: binary provenance, ships a vulnerable prebuilt libwebp (cc:
localsend: binary provenance, ships a vulnerable prebuilt libwebp (cc:
golden-cheetah-bin: binary provenance, ships a vulnerable prebuilt libwebp (cc:
libreoffice sources file lists a libwebp- (or libwebp- for libreoffice-still)
, vendor libwebp via the rust crate libwebp-sys2
Ugh, and good luck finding all the things that end up transitively depending on that crate I guess. I suggested they file a GHSA so dependabot can go and do its thing, but it might still take a while to trickle down through dependents. Anyway, libwebp-sys2 version 0.1.8 looks like it's fixed.
There's also and I can't seem to find the vendored code by grepping for strings in the binaries. Would need further checking, but I'm tempted to say libreoffice is fine?
The libwebp-sys2 crate also will link against the system libwebp if it is found. I'm currently compiling a list of rust packages that use libwebp-sys2.
But since it transparently falls back to the vendored source, I'm going to assume most Rust programs in nixpkgs haven't bothered declaring libwebp (and pkg-config?) as buildInputs... But at least that might give us a lever to patch without requiring an upstream cargo deps bump?
the application has enabled the libwebp-sys2 'static' feature, then it will skip looking for the system one and build its own
Unsure how to deal with the libwebp-sys2 things, which would still be vulnerable for cross-compiling and pkgsStatic. Opened an upstream issue:
Hi! Sorry for just popping in randomly, are there any publicly available workarounds for this issue currently? I'm on , but it seems like firefox nor others have gotten their version bump on that branch.
Not really, and as noted in this issue's description relying on the browser's version number is misleading here (because nixpkgs doesn't use the vendored libwebp, so what matters is the version of the libwebp dependency). If someone wants to write instructions using I'll gladly add those to the issue description for future reference.
On the branch we're only missing a few thousand builds per platform right now, so I'd hope for to update tomorrow.
From the : So looks like this one is fine. I'd remove the vendored download to prevent confusion, but looks like this is automatically generated...
staging-next was merged to master, so users on nixos-unstable should have their browsers patched on the next channel bump.
Fixes for Tor Browser & Mullvad Browser:
Hi! I use the branch specifically in my flake, any ETA on when that branch will get the update pushed?
Depends on how fast stuff ends up rebuilding, I'd expect within 1-2 days at the latest. It's all in automation's hands at this point, unless there's somehow a breakage we didn't notice. You can switch to which already has it (but might require you to do more rebuilds from source), or follow for the status of the fix.
I think I might channel-switch for a bit for this fix, thanks for the help!
Additional packages which have a vendored libwebp that I found on my system via the that posted in Matrix: slack obs-studio (via ) openutau (via embedded , also oops this package is mine )
Same method as mentioned by Lily, found: android-studio discord idea-community vial (via ) joplin jetbrains-jdk-jcef (via ) qtimageformats (via )
I looked more into .NET apps that depend on Avalonia and I've also confirmed these vendor libwebp (all via ). I've not confirmed that any of them use the vulnerable version directly, but it seems highly likely they do given a new SkiaSharp release has still not been made since the release of the CVE fix: BeatSaberModManager alttpr-opentracker avalonia-ilspy denaro galaxy-buds-client git-credential-manager jellyfin mission-planner mqttmultimeter ryujinx scarab space-station-14-launcher wasabiwallet
same method as hexa and liliy
currently working on a betterbird update. Not sure about thunderbird and I don't really have the time to check it right now. edit
Also going to add onlyoffice-bin, libsForQt5.qt5.qtimageformats, libsForQt6.qt6.qtimageformats and remarkable{,2}-toolchain to the naughty vendoring list.
If it uses buildMozillaMach it uses our system package.
Got a match for "no memory during frame initialization." in : /nix/store/z613gjk28c3q0ypjsdch9vshdlydc9fm-vscodium-1.82.0./lib/vscode/codium
I've ran a grep on ~200K Nix store paths from a full Hydra evaluation - here are the results: Let's start categorizing that a bit and translating it into trackable tasks :) I've already listed all the SkiaSharp dependents. A few other categories I see: CEF users Vendored Electron users Qt libs Flutter Go binaries (e.g. mautrix-whatsapp, but not sure what package the dep is coming from)
For reference, I believe that all supported channels (6) have updated past the patching (the non-vendored one). This weekend turned out to be a pessimistic estimate.
golden-cheetah-bin: PR to mark insecure: Also reported upstream:
opencv seems like a relatively common package (with multiple versions). Maybe the maintainer could have a look?
High priority things that I think are still to be updated: Chat apps / browsers / mail clients: fluffychat (uses vendored flutter < v3.13.4, cc upstream has a commit in master which updates flutter to 3.13.4, but I don't think that's released yet. gitter (cc upstream seems unmaintained anyway, should be removed?) mautrix-whatsapp (vendored via some Go dep, cc signal-desktop-beta (cc who took care of Signal, can you maybe have a look?) threema-desktop (lib/threema/threema-web - is this even used? since we use nixpkgs electron, cc tutanota-desktop (opt/tutanota-desktop/tutanota-desktop - similar to threema-desktop, also cc
mattermost-desktop (share/mattermost-desktop/mattermost-desktop, cc
rocketchat-desktop (cc I think just needs a bump to 3.9.7 for
Yeah removing gutter seems fine
do you recommend moving FluffyChat from stable -a git commit temporarily? By the way, flutter itself seems to have a bad vendored version. Need to push out 3.13.4.
There's a mautrix-whatsapp bump here: , not sure how I can check whether this is fixed by that PR? Edit: looked into the upstream source, definitely not fixed by that PR. From what I can see mautrix-whatsapp uses libwebp in a vulnerable way. I'll try to work with upstream to get this resolved.
If cherry-picking the patch is an option it's probably less invasive, if upstream is planning a release in the next 2-3 days I think I wouldn't mind waiting too. If neither of these options apply (or if you don't mind bumping twice in rapid succession if upstream pushes a new release) going to an unstable version SGTM.
was updated and merged recently (). Would that count?
Looks like that new version contains which is a proper fix. Thanks for the pointer! Just needs backport to 23.05 now.
It was mentioned in the changelog, please read them when updating a package.
It will count once the backport to release-23.05 has happened.
I had already reported the issue to mautrix-whatsapp in private to lessen the chance of exploitation (they use the webp dependency to decode webp images and are thus vulnerable). I've had no response yet though.
Heh, I don't think there's much value in reporting this in private (and making coordination/tracking harder) given that it's a publicly disclosed vulnerability already. I noticed you said you'd talk to upstream but couldn't find any trace of that, so I went ahead and filed that bug... Sorry for stepping on your toes - it's hard for me to know exactly how actively maintainers are going to handle the remediation by themselves, so I've been proactive in making sure upstream issues are filed when I don't see one
Godot (godot3, godot_4, godot3-headless, godot3-server, godot3-export-templates): upstream has merged which I think is getting backported to the 3.x branch. But it also appears that, at least for 4.x, libwebp can be unvendored: I think that's what we should be doing while waiting for new releases, and this is likely true of many other dependencies that can be unvendored via the same mechanism. cc maintainers: (please cc me on any fix PR and make sure to backport to 23.05).
Fix for mautrix-whatsapp here: (backport here: )
Worth noting is vulnerable, upstream fix was in PR Kong/insomnia, though it hasn't gotten a release yet.
is a fix for signal-desktop-beta, thanks
:heart: to all who have contributed to this.
Explicitly pinging the maintainers for the remaining high-risk use cases: armcord still uses vulnerable Electron 26.1.0. Please get upstream to fix their security vulnerabilities. caprine-bin is presumably built by upstream from Electron 24.1.3 from 151 days ago. Please get upstream to fix their security vulnerabilities. (Additionnally, why is this a binary build instead of something we build from source?) - mailspring uses Electron 17, which is hopelessly out of date, EOL, and insecure. Please get upstream to fix their security vulnerabilities.
mattermost-desktop is out of date in nixpkgs. Their latest release is based on Electron 26.1.0, which is also insecure. Please get upstream to fix their security vulnerabilities. rocketchat-desktop also needs a bump in release-23.05. I've started the backport process via the master PR, please test it and let me know when it's ready to be merged. - Everything in this list that hasn't been updated by Friday 2023-09-29 00:00 UTC will be marked as insecure next weekend.
Also mentioned this on Matrix, but for posterity: SideQuest is also affected (and frequently loads untrusted content). It appears to use a bundled Electron 13, which has not received and will not receive a patch. I've e-mailed the upstream in the hopes that they can update to a newer Electron ASAP.
Using and then checking the output of by opening DevTools (Ctrl+Shift+I) : <- patched according to GH security advisory : <- patched according to GH security advisory : <- vulnerable? Tested on
Great, thanks for looking into it! Hopefully they'll roll out that update to the stable branch soon... I guess it's difficult for a small indie developer like them, it's only been 2 weeks since the fix was made available! :-)
just got updated in master so it's not in nixos-unstable yet. thanks for checking it out, I couldn't figure out a way to check the electron ver.
Thanks! I checked 0.0.30 (which is on master and 23.05 as of yesterday) and it seems to be on Electron 22.3.24. Marking as fixed
Thanks for pinning me. Just created an issue there: Because the source build failed the time I tried to package Caprine (some years ago). It's a pain to an build Electron app from source in Nixpkgs.
Regarding Mailspring there is , I will ask about their plans to move forwards
There should be a pre-release with electron 27 for armcord, will dig in tomorrow.
Currently we are not building koreader from source (see for some efforts).
Since the released upstream deb package has not fixed CVE-2023-4863 ( fixed it, but it is not released yet), we have to wait a while for a new koreader release.
To make it better, I reported them this like 2 weeks ago! They're still working on running the npm command on the stable branch, give them some time!
fluffychat and flutter updates have been backported now:
I made a draft PR that contains the caprine-bin update (), but the updated app turns out to be unusable (sindresorhus/caprine).
The above issue is resolved in Caprine 2.58.3. Please take a look at .
it was brought to my attention that the Darwin version for Discord was not bumped in 6 months, and is thus still vulnerable to this libwebp vuln. If nobody maintains this software can it be removed and/or marked as knownVulnerable? Thanks!
I'd say that after a bit of wait you mark packages as vulnerable and that is the main way of finding out whether someone is really willing to keep it alive.
I have bumped them in . The main issue is that r-ryantm isn't helping us out here, as there is no for the darwin packaging. Not sure if any of the other Discord maintainers are using Darwin, but I certainly don't and would need some assistance testing these.
is affected. I created mifi/lossless-cut to remind the LosslessCut upstream to make a new patch release, so that me can update .
is affected, fix:
All the packages I evaluated as being high-risk have now been taken care of (and most of them did actually get updates, woo! only marked 2 or 3 as insecure). Right now I don't think anyone has the bandwidth to try and track the rest. I'm going to close this bug - if someone does want to take over the remediation for the rest of the impacted packages, feel free to reopen and assign yourself. (Note however that there is a large overlap between vulnerable to this libwebp vuln and vulnerable to the recent libvpx vuln... so maybe just go help over there instead of reusing this bug.)
Unpinning due to closing
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Package name: kitty Latest released version: 0.34.1 <!-- Search your package here: --- Current version on the unstable channel: 0.34.0 Current version on the stable/release channel: 0.31.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
prints The message seems misleading as everything works as expected, even as a regular user. = { enable = true; locate = pkgs.mlocate; }; System: (NixOS: ) Nix version: () Nixpkgs version: ()
This still happens, although its a correct warning
That's surprising since it works for me without root. I only experienced issues when the wrong binary is used. If I recall correctly has higher priority and causes this. Can you check the output of or paste whatever error you get?
Sorry hit the wrong button by accident.
The warning is correct, but the wording is misleading. What it’s trying to warn you is not that will only run as , but rather that will run as . You can prevent the warning from being shown (with no other effect) by explicitly requesting that run as with .
This is warning is still confusing to me. If I'm building an index of files, I'd expect that if I run it as a non privileged user many files will not be reachable and therefore these won't end up in the locate database/index. Given the way works, I'd also expect to have one database per system, not one per user. So from this my expectation is that can only successfully index everything if run as . In other words, I'm still not sure what is the purpose or goal of the message. Is it just that the command needs to run as ? is this bad in any way? why is this special given the purpose of the tool? Is it that the fact that it runs as is in some way a security concern? Is this to clarify that despite the existence of an group (and user?) these are not actually used for indexing, or is the point something else entirely. Do other tools work in such a different way that justifies the existence of this warning for ?
mlocate’s doesn’t have a option like findutils’ does. Therefore, the NixOS module ignores when using mlocate (). It prints a warning to indicate that your expectation has been violated. The group is there so that the mlocate binary can be setgid rather than setuid . Given that mlocate is designed with an that indexes everything and a that only shows you your own files, there doesn’t seem to be much point in running mlocate’s as another user.
If you want that, why not switch back to findutils?
I see, in this context, the above makes sense. I actually want the full system indexing. To me has always been a synonym of , except several times faster. Thanks for the clarification!
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Could you include your commit in a pull request? I think that's a good solution and we can close this issue.
It’s been in this whole time.
My bad, I read only the latest updates and the pull request was higher up. Did a bit of noise on the pull request. It's a harmless change so I was surprised to see it sitting there for this long.
To avoid , this is needed: it's needed because it creates the group. That error happens when using: with or without: and then doing something like . But if not using the (so only using the alone) then there's no error, because the service itself uses a different package's by default, it's from package. The source: EDIT: I made some mistakes initially, you can see post history for that.
The pijul fetcher throws a certificate error when used, for example with the following command: Related: Steps to reproduce the behavior: fetchpijul (for example like in the command above) fails with above error Repository gets fetched successfully Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Oh my, thanks for notifying, I'll make a PR to fix that ASAP!