NixOS Foundation

Mentors: Student: Darshan Thakare

This project focuses on improving the accuracy, reliability, and observability of the Nixpkgs Security Tracker by addressing key limitations in its current CVE–derivation matching pipeline. At present, the system relies on overly permissive substring-based matching, incorrect string-based version comparisons, and lacks proper monitoring, which leads to noisy results, missed vulnerabilities, and silent failures. The proposed work introduces a structured, test-driven redesign of the matching pipeline. It replaces flawed string comparisons with semantic versioning to ensure correct handling of version boundaries. It also improves matching quality by incorporating multiple signals such as trigram similarity, CPE-based matching, and version constraint filtering, thereby reducing noise and increasing the precision of candidate derivations. In addition, the project strengthens data integrity and consistency by fixing cache update issues, eliminating race conditions in issue generation, and ensuring that the system always reflects the latest state after manual or automated changes. It also introduces observability through metrics and dashboards, making system behavior measurable and exposing previously hidden failure cases. Finally, the proposal removes hardcoded infrastructure by enabling dynamic, database-driven channel selection, improving maintainability and scalability. All improvements are guided by measurable metrics and validated through tests to ensure correctness and prevent regressions. Overall, the project aims to deliver a more accurate, robust, and transparent security tracking system for the NixOS ecosystem.

Mentors: Student: prescientmoon

NixOS vars allow declaring secrets that live inside (or outside) the nix store in a declarative manner. Vars already have a WIP implementation over at https://github.com/NixOS/nixpkgs/pull/370444. The project would involve me working with Lassulus (the author of said PR) on finalizing the implementation. The long term end goal is having an upstream solution to the issues tools like sops-nix and agenix are currently solving (all while remaining agnostic to the underlying format). After speaking to Lassulus, the goals I'd be working on are: - writing a good example backend implementation - thinking about and solving some remaining architectural questions (when do the vars get generated, and how that affects the system itself) - defining a clean & clear interface for third party backend implementations Answering the above questions would require studying existing solutions (clan-core, nixos-artifacts, agenix-rekey) and picking out the best ideas from each.

Mentors: Student: Amrit Amber

The Nix build hook mechanism has been marked for removal since 2017, but it still fills an important gap in Nix's distributed build architecture. In particular, it is currently the only interface that can pass a build request together with its full set of input paths atomically. Store-based remote building does not provide this: it splits the process into separate calls, which makes it difficult for builder stores that schedule builds across a cluster, such as "nix-scheduler-hook", to know where inputs need to be copied before the build is assigned. This project proposes a cleaner, more extensible replacement by adding a new virtual "buildDerivation" method to the "Store" base class. This method would bundle the derivation path, derivation, and input paths into a single call, preserving the atomic behavior that cluster schedulers rely on. To ensure compatibility, the new interface would include a default implementation so that existing store backends continue to work unchanged. The project will validate this design through an end-to-end proof of concept by adapting "nix-scheduler-hook" to use the new API. Once the new mechanism is confirmed to support distributed scheduling correctly, the legacy build hook mechanism can be removed from the Nix daemon. Expected deliverables include the new virtual "Store" method and its default implementation, full removal of the build hook mechanism from the Nix daemon, a proof-of-concept "nix-scheduler-hook" adaptation, a passing distributed build test suite, and accompanying API documentation and migration guidance.

Mentors: Student: Tanishq Palandurkar

NixOS is uniquely positioned to generate accurate, reproducible Software Bills of Materials (SBOMs) from its declarative build graph, yet current SBOM generators must infer Package URLs (PURLs) from package names and heuristics leading to inaccuracies that matter under regulations like the EU Cyber Resilience Act. This project fixes the problem at the source: 1. by enriching nixpkgs package metadata so that correct PURLs are embedded directly into derivations, eliminating guesswork downstream(SBOM generators like bombon, sbomnix etc). The core blocker is that passing meta attributes through .drv files currently risks triggering massive content-addressed reverse dependency rebuilds. This project will help land the key upstream PRs (notably Robert Hensing's PR #14686 / nixpkgs #466932) that allow selected metadata to flow into .drv without affecting store path computation. With that foundation in place, a systematic series of nixpkgs PRs will enrich packages that currently carry inaccurate or missing PURL metadata, while coordinating with SBOM tool authors (e.g. bombon, Syft, sbomnix) to reduce heuristics and consume the authoritative data. Deliverables: 1. community coordination to get the PRs blocking enrichment merged 2. a batch of nixpkgs enrichment PRs covering packages with known PURL inaccuracies 3. upstream patches or issues filed against SBOM generators to adopt the enriched metadata

Mentors: Student: Yurii Shymon

As part of GSoC campaign, I'd like to add a sort of networking library to nixpkgs. Most general-purpose programming languages support network primitives and operations between them. By adding support for such primitives to nixpkgs, service declarations can be greatly simplified. It's much nicer to deal with built-in types like ipv4/ipv6 (and others) instead of raw strings. Deliverables: * Network library with primitives and wide functionality. * Several existing services are rewritten to use the library. * Comprehensive unit tests for the library. * Function api and general documentation.