GSoC 2026
NixOS Foundation

NixOS Foundation — Project Ideas

View Original

Ideas

Welcome to our Google Summer of Code ideas list!

Review Nixpkgs PRs

Effort: Small (90 hours) - Large (350 hours)

Nixpkgs is the largest package repository with over 120k packages. It is maintained in the Nixpkgs repository, where hundreds of active committer-maintainers are ensuring that tens of thousands of people get the latest and greatest up-to-date packages.

As such, many people including thousands of listed non-committer maintainers are submitting PRs all the time to propose changes. While there is a big number of reviewers of these PRs, we can always use more help to make sure all are tended to.

Therefore this project is about helping out with PR reviews, allowing you to get an in-depth view of various parts of Nixpkgs.

Possible mentors:

Difficulty: Easy to medium depending on choice

Activities:

  • Review updates
  • Review code changes
  • Improve smoke tests (passthru), facilitating future review / automation
  • User testing if needed, updating user documentation
  • Document merge criteria

Improved release notes for Nixpkgs

Effort: Small (90 hours) (or Medium (175 hours) with nice-to-have)

Nixpkgs and NixOS release notes are currently an unordered messy list that is barely readable: Nixpkgs, NixOS.

These release notes are often not very relevant, hard to read and cause frequent merge conflicts. This project is to add infrastructure to make each release note entry be declared in its own file, with optional extra structure and attributes, and then use this to generate better release notes. Nice to have: Generate them dynamically for the user, like the Home Manager news feature.

Possible mentors:

  • Previous release managers

Difficulty: Easy

Prior art:

Migrate some NixOS modules to modular services

Effort: Small (90 hours) to Large (350 hours)

Modular services are a new NixOS feature to reduce evaluation time as more service modules are written, contrasting the historic evaluation time increases as the central module list increased, while also supporting more flexible usage patterns like multiple instances of a service type on the same host. This project is to migrate some standard service modules to modular services. Pick a module from the module list, see if it makes sense to migrate it, and make a PR for it. Can be extended to arbitarily many modules.

Skills required:

  • NixOS configurations
  • Systemd services

Possible mentors:

  • Robert Hensing
  • Silvan Mosberger

Difficulty: Medium

References:

Security Tracker Improvements

Effort: Small (90 hours) - Large (350 hours)

Improve the Nixpkgs Security Tracker with the following enhancements:

  • Improve matching quality with more structured data and heuristics
  • Implement workflow for change proposals by maintainers
  • Enable sharing evaluation data across multiple services
  • Increase data storage efficiency
  • Fix UI problems
  • Dig into data to increase transparency or observability
  • Introduce new tools or paradigms into the development process

Skills required:

  • Web development
  • Data analysis
  • User interface design
  • Backend development

Possible mentors:

  • (Add yourself here!)

Difficulty: Easy to Medium, depending on choice

References:

Prior efforts:

  • Existing security tracker infrastructure

Testing Dynamic Derivations

Effort: Medium (175 hours)

Existing work on an experimental feature known as "dynamic derivations", which refers to derivation outputs that can themselves be derivations, lacks the adequate testing to be upstreamed. Moreover, functionality can be added to enable "lang2nix" tools to work more seamlessly. The goal is to thoroughly test this feature and add new functionalities such as methods for converting foreign packages to Nix using graphs for various package managers, creating conversion tools for Ninja and Make graphs (benefiting large builds like Chromium and LLVM), determining paths for upstream tools like CMake and Meson to integrate with Nix, and exploring modifications to language-specific package managers to utilize Nix for the actual building process.

Skills required:

  • Nix derivation understanding
  • Build systems (Ninja, Make, CMake, Meson)
  • Graph algorithms
  • Nice to have: C++ for Nix internals if you want to fix a problem with dynamic derivations

Possible mentors:

  • (Add yourself here!)

Difficulty: Hard

References:

Prior efforts:

  • Existing dynamic derivations implementation in Nix

Declarative user profile pictures

Effort: Small (90 hours)

Currently, user profile pictures as they are used in Gnome cannot be reasonably changed. The interface used for changing user icons in the Gnome system settings is unreliable (seems to only work for the preset icons). The only way to change them at all is to manually put them into /var/lib/AccountsService/icons.

The project is to make declarative user icons possible by e.g. patching accountsservice to point the user icon directory to an immutable location in /etc or systemd service to place user icons in /var/lib/AccountsService/icons. This is followed up by writing NixOS VM tests to make sure it works.

Possible mentors:

  • (Add yourself here!)

Difficulty: Easy

References:

Enhanced Patch Information Extraction

Effort: Medium (175 hours)

Improve the mechanisms for extracting and exposing information from patches in nixpkgs. This includes better metadata extraction, structured data output, and potentially machine-readable formats for downstream tooling integration.

Skills required:

  • Nix expression evaluation
  • JSON handling
  • Metadata extraction patterns

Possible mentors:

  • (Add yourself here!)

Difficulty: Hard, because it's open ended and requires some research to find a good solution

References

Cross-Ecosystem Vendored Dependencies

Effort: Medium (175 hours)

Currently, retrieving vendored dependencies is ecosystem-specific. This project aims to create a unified mechanism for fetching vendored dependencies from any package, regardless of the ecosystem (Rust, Dart, Go, etc.). This would provide a consistent interface for handling vendored code across different language ecosystems. For instance the Nixpkgs function for building a Go package could be extended with a "pass-through" derivation that reports what the vendored dependencies are, so that this information can be integrated into the security tracker later.

Skills required:

  • Advanced Nix internals knowledge
  • Understanding of multiple ecosystems (Cargo, pub, Go modules, etc.)
  • Fetcher implementation experience

Possible mentors:

  • (Add yourself here!)

Difficulty: Medium

References:

Prior efforts:

Refactor Remote Builder Library

<!-- TODO: Needs more details -->

Effort: Medium (175 hours)

Currently the remote builder code in the Nix daemon is implemented as a monolithic processConnection function, with customization limited to passing a custom store. This project aims to refactor this code into a separate library, making it easier to implement custom remote builders and improving code maintainability.

Skills required:

  • C++ for Nix daemon internals
  • Understanding of Nix store architecture
  • Socket programming and SSH knowledge

Possible mentors:

  • (Add yourself here!)

Difficulty: Hard

References:

SBOM Accuracy and PURL Integration for Nixpkgs

Effort: Small (90 hours)

Software Bills of Materials (SBOMs) generated from nixpkgs packages often suffer from inaccurate package identifiers, making vulnerability scanning and supply chain analysis unreliable. This project aims to improve SBOM accuracy by adding proper PURL (Package URL) attributes to nixpkgs package metadata, ensuring consistent and accurate package identifier generation for SBOM output in multiple formats (SPDX, CycloneDX), and creating validation tools to verify SBOM accuracy. The project will integrate with existing tools and ensure compatibility with vulnerability scanners.

Skills required:

  • Nix expression evaluation and metadata handling
  • Understanding of PURL specification
  • SBOM format knowledge (SPDX, CycloneDX)
  • JSON/XML processing

Possible mentors:

  • (Add yourself here!)

Difficulty: Medium

References:

Prior efforts:

Statix Nix Linter Improvements

Effort: Small (90 hours)

Statix is a linter for the Nix programming language. This project aims to continue its development, adding new lints, improving existing ones, and potentially expanding its capabilities for detecting anti-patterns and suggesting improvements in Nix code.

Skills required:

  • Rust or Haskell (Statix is written in Rust)
  • Nix programming language expertise
  • Compiler/linter development

Possible mentors:

  • @mightyiam

Difficulty: Medium

References:

Slightly progressed fork:

Draft Ideas

Patch CVE Reference Cleanup

Problem: Doesn't seem like code, more like data maintenance

Many patches in nixpkgs fix CVEs but don't properly reference the CVE identifiers. This project involves auditing existing patches, identifying those that fix CVEs, and ensuring they properly reference the relevant CVE numbers. This improves the security tracking capabilities of the Nixpkgs Security Tracker.

Skills required:

  • Basic Nix and nixpkgs knowledge
  • Research and documentation skills
  • Understanding of CVE identification

References:

Prior efforts:

Package Wrapper Metadata in Nixpkgs

Problem: Unclear? How to go about this? What's the benenfit?

Some packages in nixpkgs are wrappers around existing packages, but this metadata is not consistently tracked. This project would add proper metadata to identify wrapper packages and ensure the unwrapped attribute is consistently applied, improving package discoverability and maintenance.

Possible mentors:

  • (Add yourself here!)

Skills required:

  • Nixpkgs structure knowledge
  • Package evaluation understanding
  • Documentation skills

Greater usage of updateScript throughout Nixpkgs

Let's make more use of the Ryan(Tm) update bot!

  • add updateScripts
  • add tests to existing scripts that are failing
  • create a metric to analyze existing script pass/fail/update-time

Command Palette

Search for a command to run...