Open Aleksanaa opened 2 months ago
the SRI hash is obtained, which causes some confusion.
You can still use the SRI sha256 hash in the sha256
attr.
(Not disagreeing with the deprecation though.)
(Taking the opportunity to plug the related lib.fakeHash
, which maybe only I use, because it lets you avoid remembering how many A
s you need.)
You can still use the SRI sha256 hash in the
sha256
attr.
Yes, it's like sha256 = "sha256-..."
, if after some day we decide to use sha512 by default, it will become sha256 = "sha512-"
@emilazy
I usually just use ""
honestly, as Aleksanaa mentioned.
Anyway, discussing strategy: should we remove the usages first for a given fetcher, before we add the warnings?
And your example bash script, it may work safely for something like cargoHash
as you did in https://github.com/NixOS/nixpkgs/pull/323983, because we know it will only affect the rust builder/fetcher. But sometimes people use custom builders and scripts (especially update scripts) that may break with this. I will try to come up with a more robust script that only touches one fetcher at a time.
Anyway, discussing strategy: should we remove the usages first for a given fetcher, before we add the warnings?
Yes, otherwise ofBorg will fail?
I will try to come up with a more robust script that only touches one fetcher at a time.
I'm adding one more grep like grep -rl "fetchFromBitbucket" . | xargs grep -r 'sha256 = ' | while IFS= read -r line; do
and it turned out well. But update script is indeed a problem and it is not within the scope of our scan.
(Thank you, I had no idea ""
works! I could swear it didn’t in the past. Sorry for the tangent.)
Yes, otherwise ofBorg will fail?
I didn't know borgo fails on warnings. But anyway I meant, keeping the 0-rebuild treewide in a separate PR would make it easier to avoid merge conflicts and mixing of logical changes.
I'm adding one more grep like
grep -rl "fetchFromBitbucket" . | xargs grep -r 'sha256 = ' | while IFS= read -r line; do
Some packages have multiple fetcher or people doing some custom constructs in the same file, which is why I'll try to avoid grep in this way if possible.
There are many fetchers that are based on others(fetchFromOrCz
is based on fetchzip
, fetchFrom9Front
is based on either fetchurl
or fetchgit
, etc). Will the sha256 attribute have to be deprecated in those fetchers first, or in the underlying ones?
So I wrote this script:
It depends on jq
and ansi2txt
. Currently, because it is single-threaded logic, a treewide operation takes about 10 minutes. Feel free to modify it according to your ideas.
Just noticed in the list, but fetchit
is not a fetcher, it's a podman tool. Should probably be removed.
I tried GitHub (only editing sha256 = "sha256-
), and there are 3000+ direct editions, including 1000+ objections (we can modify the check to revert changes directly, using sed or git, depending on the speed). We can still edit 2000+ files painlessly after all. Might be related to https://github.com/NixOS/nixpkgs/issues/301014
Just noticed in the list, but
fetchit
is not a fetcher, it's a podman tool. Should probably be removed.
I've given up that list, because we cannot actually determine which fetcher it is (except for those that only serve specific sites). And since they are derivatives of fetchurl or fetchzip, it is not convenient to deprecate hash for a single fetcher
When we did not support SRI hash, we wrote a lot of
sha256 = "..."
, and some of new PRs are still written with this attribute. However, when using an empty string to obtain the correct hash from the error, the SRI hash is obtained, which causes some confusion.Let's move on from this old attribute. I don't expect to remove it within a certain period of time, but we can throw a warning to prevent this type of writing from continuing to appear in nixpkgs.
I did an experiment last time with cargoHash in https://github.com/NixOS/nixpkgs/pull/323983. I wrote the following script for this:
We can deprecate each fetcher's sha256 separately, instead of the entire hash, to avoid the burden of review:
I collapsed the check list because it's not feasible to deprecate one by one
- [ ] fetch-scm - [ ] fetchCrate - [ ] fetchDebianPatch - [ ] fetchDockerConfig - [ ] fetchDockerLayer - [ ] fetchFirefoxAddon - [ ] fetchFrom9Front - [ ] fetchFromBitbucket https://github.com/NixOS/nixpkgs/pull/326028 - [ ] fetchFromGitHub - [ ] fetchFromGitLab - [ ] fetchFromGitea - [ ] fetchFromGithub - [ ] fetchFromGitiles - [ ] fetchFromRepoOrCz - [ ] fetchFromSavannah - [ ] fetchFromSourcehut - [ ] fetchHex - [ ] fetchMavenArtifact - [ ] fetchNextcloudApp - [ ] fetchNpmDeps - [ ] fetchNuGet - [ ] fetchPypi - [ ] fetchPypiLegacy - [ ] fetchRepoProject - [ ] fetchTarball - [ ] fetchYarnDeps - [ ] fetchbower - [ ] fetchbzr - [ ] fetchcvs - [ ] fetchdarcs - [ ] fetchdocker - [ ] fetchegg - [ ] fetchfossil - [ ] fetchgit - [ ] fetchgitLocal - [ ] fetchgx - [ ] fetchhg - [ ] fetchipfs - [ ] fetchit - [ ] fetchmail - [ ] fetchmail_7 - [ ] fetchmtn - [ ] fetchpatch - [ ] fetchpatch2 - [ ] fetchpijul - [ ] fetchs3 - [ ] fetchsvn - [ ] fetchsvnrevision - [ ] fetchsvnssh - [x] fetchtorrent (Looks like there is no support for sha256 attribute?) - [ ] fetchurl - [ ] fetchutils - [ ] fetchzip