treewide: Migrate rev -> tag batch 1#418147
Conversation
|
|
|
I always prefer rev over tag since a tag can be reassigned to another commit. Are you sure it's okay from security perspective? |
Yes, let's say you create a tag that has the same value as a revision. In that case, doing rev = version;or tag = version;Will not be different, and that is clearly an issue. This is why, people started to use: rev = "refs/tags/${version}";To explicitly use a tag and not a revision. This is precisely why the |
thank you for explaining! but changes in this PR are |
|
Yes, but here the revs are tags actually, so, what's in this PR is legit. |
I really doubt that this is a good move. in fact one of the reasons I like nixos is that it's encouraging using hashes to refer to source codes. is there any documentation or design behind these changes? |
|
I forgot to mention that this move is on the opposite direction of forcing reproducibility principle! reproducibility was the goal of nix and as far as i know it still is. if we go to this path we basically will add a new class of bugs, which i use nix to prevent them! |
|
Could you please make your point? I still don't get it. Why would you prefer: rev = version;over tag = version;? |
I checked the changes again. All of them have sha-256 hash, so I guess I am okay! thank you for bearing with me! 😄 |
That's precisely wrong. If the version attribute is not a human readable version (aka, a hash), then switching to |
yes I confirm the versions are human readable, but what makes me sure the tags didn't move is the existence of sha-256 beside the tags. I already approved. 🙂 |
Of course, but a hash is mandatory if you have a |
|
Migrate rev -> tag
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.