The fix for the recent GLIBC advisories CVE-2023-6246, CVE-2023-6779, and CVE-2023-6780 is now merged into the NixOS master and nixos-unstable branches; I'm not sure about the NixOS 23.11 release, since I couldn't find the commit.

GitHub

glibc: 2.38-27 -> 2.38-44 and patch for glibc possible memory corruption in qsort() by LeSuisse · Pull Request #285050 · NixOS/nixpkgs

Description of changes Fixes CVE-2023-6246, CVE-2023-6779, and CVE-2023-6780 Advisories from Qualys: https://www.qualys.com/2024/01/30/cve-2023-624...

BTW, NixOS unstable is not actually unstable. It's just a rolling release. Which in my opinion is MUCH better than using releases; I don't get hit with a ton of changes all at once. I use the master branch, and even that is often stable. #nixos #nixoskicksass

Beware of CVE-2023-6246, a GNU C Library (glibc) privilege escalation vulnerability:

Stacker News

New Linux glibc flaw lets attackers get root on major distros \ stacker news

Unprivileged attackers can get root access on multiple major Linux distributions in default configurations by exploiting a newly disclosed local pr...

I checked NixOS, and the fix is on the way.

Did you know that Discover doesn't hold you responsible for unauthorized purchases? That's what the dinosaurs are advertizing... #memestr

This is cool. The AppImage I created of the Gossip nostr client uses glibc. I built the AppImage such that it contains *all* of the dependencies, all the way down to glibc and OpenGL drivers; This is a fat (~300MB) AppImage! But in theory, that means it can run on a wider variety of x86_64 Linux distributions; Usually, AppImages despite how they are described, are targeted at the base install of a specific distro, such as Ubuntu. I don't think that fulfills the vision of an AppImage, but I digress. Therefore, I decided to test the theory by attempting to run the AppImage on the musl version of Void Linux. That would ensure that the AppImage doesn't depend on the host OS's libc. I took it a step further and didn't install the VirtGL drivers. That way, Gossip would have to fall back to software rendering using llvmpipe. And... it worked! The image above shows that the host OS libc implementation is musl, the OpenGL driver is llvmpipe, and the libc implementation being used by the Gossip executable (which is running in a container) is glibc. #nix #gossip #fat-appimage #xxl-appimage

I created a process for building an AppImage out of the Gossip nostr client. It's actually quite simple because Nix does most of the work. You basically download nix-portable, which is a self-extracting executable, run a few commands, and you have an AppImage. And to clean up the build artifacts, just delete the nix-portable script and the directory $HOME/.nix-portable. No root necessary. How does it work? The AppImage is build with Nix, which is interesting enough. But there's more. The AppRun executable in the AppImage creates a Linux container so that the embedded Nix store can be mounted at /nix. The details are at the repo:

GitHub

GitHub - emmanuelrosa/gossip-appimage: A Nix flake which builds an AppImage of the Gossip Nostr client

A Nix flake which builds an AppImage of the Gossip Nostr client - emmanuelrosa/gossip-appimage

#nix #gossip

Some time ago I created a Nix function called `nvidia-offload-wrapper` which can be used to wrap a Nix package so that it renders using NVIDIA offload rendering. This was nice because you could take the Nix package for a game such as "Super Tux Kart" and add NVIDIA offload rendering without having to modify the package, nor run the package from the command line; Here's the dirty secret, the wrapper creates a symlink to the $out/share directory of the wrapped package, so that NixOS sees the .desktop file and icons, just like an ordinary Nix package. Later, I factored out the wrapping functionality to generalize it. So now it's possible to create all sorts of wrapper functions with very little Nix code. More recently, I added a new wrapper function which creates a launcher to run a Nintendo 64 game using `mupen64plus`. With this function, you can run a N64 ROM as seemless as running a native Linux application; It creates a .desktop file. Sometimes it makes sense to apply multiple wrappers to a package. What if you want to run a N64 ROM using NVIDIA offload rendering? Overkill, I know, but I'd be cool. As of now, not only are the wrapper functions composable, I added a couple of composition functions to make it easier. For example, instead of `x = func4 (func3 (func2 (func1 arg)))` you can do `x = (compose [ func1 func2 func3 func4 ]) arg`. `compose` makes more sense if you can to assign the composed function a name and use it later. If you can to compose some functions and apply then in one go, `composeAndApply` is bit cleaner: `x = composeAndApply [ func1 func2 func3 func4 ] arg`

GitHub

GitHub - emmanuelrosa/erosanix: My main NixOS/Nix Flakes repository

My main NixOS/Nix Flakes repository. Contribute to emmanuelrosa/erosanix development by creating an account on GitHub.

#nix #nixos

Since 2023 has been rather... shitty, I thought I'd create something fun:

GitLab

Emmanuel Rosa / sm64nix · GitLab

GitLab.com

I created a Nix flake for building and installing the unofficial PC port of Super Mario 64. The flake doesn't contain the ROM, but it does contain packages for a few HD texture packs :) There are a number of forks, but I only packaged the "Render96" fork, without RTX; I don't have the hardware to test the raycasting/RTX build.