This has been marked insecure a while ago, as some CVEs have not been
backported. Even if *some* CVEs are fixed, we'd need **all** of them to
be, to get it back into the cache.
Not having it in the cache means, we can not test it in CI. This means
we can't make sure to actually support this version to evaluate Nixpkgs.
Currently, the output from fetchtorrent will be different depending on
whether the default "transmission" backend or the "rqbit" backend is
used, because "rqbit" changed its behaviour in v6.0.0 to create
subdirectories.
Restore the old behaviour for the rqbit backend of flattening the
directory structure, but add a "flatten" argument to allow users to
explicitly request the behaviour without this change.
Because fetchtorrent produces fixed-output derivations, it's possible
that people won't notice the changes in behaviour here, so add a warning
that the behaviour might be unexpected (in either direction!) if the
flatten argument isn't specified for the rqbit backend, and -- to avoid
needing to support it indefinitely -- a warning that `flatten = false`
will be deprecated in future.
Update the fetchtorrent tests to check all the relevant combinations,
and to mark all tests as now working.
Update the release notes to advertise this breaking change.
Fixes#432001.
With this argument fetchgit will make a subdirectory of the Git
repository a root of the resulting store path. This is helpful for
dealing with monorepos where many projects are in separate directories
and don't need a new source hash every time the monorepo is updated.
Commit hash is removed from the name of the derivation to prevent it
from changing the store path when nothing in the subdirectory changes.
According to emilazy these were the only usages of sha1 in nixpkgs:
```
pkgs/servers/mx-puppet-discord/node-packages.nix
111: sha1 = "532e01241dbcb0f2769f1b9a7cde313d30101173";
120: sha1 = "68018cab4f59834b3fef2e59fbfd52938403e001";
129: sha1 = "52b0e8bb808a1202602899af67939b049dd42402";
138: sha1 = "0a37a3f9430ff7c29512d29882e25ae738a31283";
```
Anyone motivated to maintain it can feel free to restore this, it's just
not maintained at the moment, and the sha1 hashes need to go.
This was found after Ericson proposed implementing something like
https://github.com/NixOS/nix/issues/13544 in Lix, which led to the
question "who is using sha1 anyway?" and the realization we could just
*remove* support for it outside of .. the known chromium crimes.
