Olm was marked as vulnerable in e4767b47.
The issue, however, is controversial and the practical ability to
exploit its vulnerabilities has not been demostrated: ultimately the
users are invited to decide for themselves.
Given that, hydra should still build and distribute the packages
depending on olm to avoid expensive builds in the event the users
decide it's acceptable to continue using these packages.
In https://github.com/NixOS/nixpkgs/pull/328582 we broke the nixpkgs
release.nix by committing an unsound tarball. We comment out freebsd for
now until this has been replaced with a proper public one.
While using very old compilers is a fair usecase, it induces a maintenance churn as
we collect more and more LLVM versions for the LLVM maintainers.
Especially when we need to backport uniform changes to the whole tree,
furthermore, it consumes and waste CI resources.
This will allow us to regenerate our woefully out-of-date
aarch64-unknown-linux-gnu musl bootstrap tools, which can't compile
lots of modern code.
We could technically also do i686-unknown-linux-musl bootstrap tools,
but I don't know if there's demand for that, so it's best to wait and
see if somebody asks for it before we commit Hydra to it.
This will allow buliding bootstrap tools for platforms with
non-default libcs, like *-unknown-linux-musl.
This gets rid of limitedSupportSystems/systemsWithAnySupport. There
was no need to use systemsWithAnySupport for supportDarwin, because it
was always equivalent to supportedSystems for that purpose, and the
only other way it was used was for determining which platforms to
build the bootstrap tools for, so we might as well use a more explicit
parameter for that, and then we can change how it works without
affecting the rest of the Hydra jobs.
Not affecting the rest of the Hydra jobs is important, because if we
changed all jobs to use config triples, we'd end up renaming every
Hydra job. That might still be worth thinking about at some point,
but it's unnecessary at this point (and would be a lot of work).
I've checked by running
nix-eval-jobs --force-recurse pkgs/top-level/release.nix
that the actual bootstrap tools derivations are unaffected by this
change, and that the only other jobs that change are ones that depend
on the hash of all of Nixpkgs. Of the other jobset entrypoints that
end up importing pkgs/top-level/release.nix, none used the
limitedSupportedSystems parameter, so they should all be unaffected as
well.
We were caching this insecure package as part of a decision during 23.05, we will now cache
openssl-1.1.1u too as this is now the de-facto OpenSSL package on 23.05, which is EOL.
Until the 11 September 2023, those two packages will be built and cached by Hydra so they can be used
by users without recompilation penalties.
This is an exception due to mismatched release windows and should not set any precedent
without community discussion in coordination with release managers.
This change exposes symbol override that accidentally caused job loss on hydra:
$ nix repl ./release.nix
error: jobs: Unexpected attribute collision between 'jobs' and 'pkgs': stdenvBootstrapTools
Added assert makes sure attribute clashes would not be re-introduced.
Commit 5643714dea introduced a tiny
bug, neglecting to pass the `pkgs` parameter to `release.nix`.
This bug went unnoticed because commit
e663518d18 had introduced a much larger
bug: an attribute collision resulted in `stdenvBootstrapTools` being
shadowed, and therefore never evaluated. As a result, the missing
`pkgs` parameter did not lead to an error.
This commit passes the missing parameter so that fixing the
larger/earlier bug will not cause an eval failure.
