RFC: Minimise accidental users of minimal-bootstrap package set

[emilytrau]

Background

The minimal-bootstrap package set's goal to provide an opaque replacement for bootstrap-tools in the stdenv. The chain to get from the seed binary to that point includes many packages that may be outdated, insecure, or contain broken/missing features. In addition the research into bootstrappable builds is always evolving, and we may want to add or remove packages into the internal dependency chain without guarantee of stability. These packages are not intended to be used directly by end-users.

Issues

Tools (such as search.nixos.org, repology, etc.) currently index this package set and provide discoverability to users. Trying to use these packages in the real world will currently most likely fail, warning you that the only supported platform is i686-linux. However a more robust conditional check with better errors and documentation could be implemented to limit accidental use.

Another potential minor annoyance might be vulnerability scanning tools detecting the use of old package versions deep down in the stdenv bootstrap and triggering a false-positive. Example (repology)

There are some tools that evaluate this package set that we do want to keep working. An important example would be Ofborg's eval checks and maintainer pings.

Ideas

• Adding a config flag that guards usage of the package set with explanation and background information in an error message.
• Renaming minimal-bootstrap to something in a similar spirit to ReactJS's __SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED

I came up with two potential improvements but neither would completely solve all the issues. I'm very interested to get everyone's ideas and comments to work together for a solution.

Maintainers

@amjoseph-nixpkgs @Artturin @Ericson2314 @06kellyjac @siraben

[emilytrau]

Related #227914

[Ericson2314]

I think I would just create a new meta field, and then ask other tools to respect it.

See also https://discourse.nixos.org/t/nixpkgs-cli-working-group-member-search/30517 which would give Nixpkgs more direct control over the JSON Repology gets, rather than hoping nix-env does what we want.

[ghost]

(I liked the original title better; Nix has a culture-specific redefinition of what "RFC" means, and an entire baroque process for doing them).

Another potential minor annoyance might be vulnerability scanning tools detecting the use of old package versions deep down in the stdenv bootstrap and triggering a false-positive. Example (repology)

Honestly this sounds like a problem with Repology, not Nixpkgs.

Trying to use these packages in the real world will currently most likely fail, warning you that the only supported platform is i686-linux

Easy solution: don't expose it as a top-level entry in all-packages.nix. Make it private to pkgs/stdenv (which is where we should consider moving it once we are ready to make the switch).

[Ericson2314]

I would not like to just put in pkgs/stdenv because I have long wanted to separate "bootstrapping" and "the standard environment" as two independent concepts.

[ghost]

I would not like to just put in pkgs/stdenv because I have long wanted to separate "bootstrapping" and "the standard environment" as two independent concepts.

Ah, I see. Okay, sounds good.

My point was that stdenv needs to reference the minimal-bootstrap result somehow, and that we can keep that reference "private" by not having it detour through all-packages.nix (or its successor, pkgs/by-name, now that the RFC is merged).

[Atemu]

Search and Repology use the packages.json we export as part of the channel tarballs. What's listed in the JSON is what they will show.

I think the solution to this issue is simply to not recurse into the minimal-bootstrap set; removing its attrs from the JSON.

There's two ways of doing that:

1. Remove the recurseIntoAttrs in all-packages.nix
2. Override it with dontRecurseIntoAttrs in pkgs/top-level/packages-config.nix

1. would stop recursion for all tools making use of nix-env to generate the whole list of packages in Nixpkgs including tools such as ofBorg, nixpkgs-review and nix-env -qa while 2. would only affect tools consuming our generated packages JSON.

[Ericson2314]

Yeah dontRecurseIntoAttrs is fine.

[emilytrau]

@Atemu would you be able to make a PR for 2 please? It sounds good, I'm just not 100% confident I understand enough to implement it right myself