Skip to content

treewide: Migrate rev -> tag batch 1#418147

Merged
JohnRTitor merged 1 commit intoNixOS:masterfrom
guylamar2006:rev-tag-1
Jun 22, 2025
Merged

treewide: Migrate rev -> tag batch 1#418147
JohnRTitor merged 1 commit intoNixOS:masterfrom
guylamar2006:rev-tag-1

Conversation

@guylamar2006
Copy link
Copy Markdown
Contributor

@guylamar2006 guylamar2006 commented Jun 19, 2025

Migrate rev -> tag

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
  • NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

Add a 👍 reaction to pull requests you find important.

@github-actions github-actions bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. labels Jun 19, 2025
@guylamar2006
Copy link
Copy Markdown
Contributor Author

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 418147

Logs: https://github.com/guylamar2006/nixpkgs-review-gha/actions/runs/15758131262

@liberodark
Copy link
Copy Markdown
Contributor

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 418147

Logs: https://github.com/liberodark/nixpkgs-review-gha/actions/runs/15758223202

Copy link
Copy Markdown
Contributor

@liberodark liberodark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LTGM

@github-actions github-actions bot added the 12.approvals: 1 This PR was reviewed and approved by one person. label Jun 19, 2025
@hadilq
Copy link
Copy Markdown
Contributor

hadilq commented Jun 19, 2025

I always prefer rev over tag since a tag can be reassigned to another commit. Are you sure it's okay from security perspective?

@drupol
Copy link
Copy Markdown
Contributor

drupol commented Jun 19, 2025

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 tag attribute has been created. It's actually a shortcut to ref = refs/tags/${value};, e.g.:

revWithTag = if tag != null then "refs/tags/${tag}" else rev;

@hadilq
Copy link
Copy Markdown
Contributor

hadilq commented Jun 19, 2025

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 tag attribute has been created. It's actually a shortcut to ref = refs/tags/${value};, e.g.:

revWithTag = if tag != null then "refs/tags/${tag}" else rev;

thank you for explaining! but changes in this PR are rev -> tag, not ref = ref/tags/ -> tag =. I understand the convenience this changes providing, but still I think keeping rev makes more sense due to the fact that upstream can reassign tags, but not rev.

@drupol
Copy link
Copy Markdown
Contributor

drupol commented Jun 19, 2025

Yes, but here the revs are tags actually, so, what's in this PR is legit.

@hadilq
Copy link
Copy Markdown
Contributor

hadilq commented Jun 19, 2025

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?

@hadilq
Copy link
Copy Markdown
Contributor

hadilq commented Jun 19, 2025

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!

@drupol
Copy link
Copy Markdown
Contributor

drupol commented Jun 19, 2025

Could you please make your point? I still don't get it.

Why would you prefer:

rev = version;

over

tag = version;

?

@hadilq
Copy link
Copy Markdown
Contributor

hadilq commented Jun 19, 2025

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! 😄

@github-actions github-actions bot added 12.approvals: 2 This PR was reviewed and approved by two persons. and removed 12.approvals: 1 This PR was reviewed and approved by one person. labels Jun 19, 2025
@drupol
Copy link
Copy Markdown
Contributor

drupol commented Jun 19, 2025

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 tag is wrong. Can you please clarify again? I guess you meant that all the versions attributes are human readable tags (aka, not a git commit id)?

@hadilq
Copy link
Copy Markdown
Contributor

hadilq commented Jun 19, 2025

That's precisely wrong. If the version attribute is not a human readable version (aka, a hash), then switching to tag is wrong. Can you please clarify again? I guess you meant that all the versions attributes are human readable tags (aka, not a git commit id)?

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. 🙂

@drupol
Copy link
Copy Markdown
Contributor

drupol commented Jun 19, 2025

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 rev as well! :)

@JohnRTitor
Copy link
Copy Markdown
Member

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 418147

Logs: https://github.com/JohnRTitor/nixpkgs-review-gha/actions/runs/15807346321

@github-actions github-actions bot added 12.approvals: 3+ This PR was reviewed and approved by three or more persons. and removed 12.approvals: 2 This PR was reviewed and approved by two persons. labels Jun 22, 2025
@JohnRTitor JohnRTitor merged commit 459f076 into NixOS:master Jun 22, 2025
33 of 34 checks passed
@guylamar2006 guylamar2006 deleted the rev-tag-1 branch June 22, 2025 19:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. 12.approvals: 3+ This PR was reviewed and approved by three or more persons.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants