sha256 - Nothing makes sense

[gitfoxi]

output path ‘/nix/store/x30f80696yvn689njc1dzqcc3ai95996-bootstrap-tools.tar.xz’ has sha256 hash ‘0i8s5nc48dpf1rvjnk22ny03ckvyk4mpydgd48g2wz687v8wip05’ when ‘1fdzbcnwmqc8n908axnzahzpr363g6w64g8jjh1vyjixj777klja’ was expected

nix-hash --type sha256 bootstrap-tools.tar.xz
4ad279ce913d4abf0394123d62b879c38c7c3f54df768540b288e1ca2d5bbfb9

Nothing makes sense.

[copumpkin]

Perhaps we should standardize on the base32 hash scheme across all of our tools?

I think they're the same hash but one is base16 and the other is base32.

[gitfoxi]

Thank you. I thought I was losing my mind.

[vcunat]

So let's close this issue?

[gitfoxi]

But then no one will know to standardize the hash.
On Feb 17, 2016 10:59 AM, "Vladimír Čunát" [email protected] wrote:

So let's close this issue?

—
Reply to this email directly or view it on GitHub
#806 (comment).

[vcunat]

You typically don't need to know. There are two formats widely used, and nix allows both interchangeably.

[grahamc]

This caused me a good bit of headache, making it very difficult to visually compare. I'd +1 standardizing on base32.

[0xABAB]

It should obviously output the code to recompute it on the shell again. These kind of error messages can only be created by someone who is just as insane as the message itself. I don't care who did it; it's just stupid beyond belief. I don't care how much useful code one writes, if someone also creates this kind of mess. At that point such a person becomes a liability and in a company you would let go of such a person. In open-source it doesn't work like that, unfortunately.

All I would like to see is that people think a bit more before they submit code to a repository which is used by more people.

[copumpkin]

@0xABAB please stay constructive. We're already putting a lot of effort (since NixCon last year and a call to arms to improve usability) into making a historically user-unfriendly tool into something more user-focused, and having someone drive-by sniping at random examples of the historical user-unfriendliness helps nobody.

[rimmington]

This bit me today: nix-prefetch-git passes the --base32 flag to nix-hash but npm2nix doesn't, which means I couldn't pass the output of the latter into the former. I've patched npm2nix for my purposes, but +1 on some consistency.

[copumpkin]

@edolstra is there any downside to standardizing on base32, other than it being slightly unconventional? I've seen several examples of it being confusing to people even outside of this ticket.

[domenkozar]

cc @svanderburg for npm2nix mention.

[vcunat]

Or all our tools might accept both on input, just as fetchurl. (It's easily recognizable just by length.) But standardizing the outputs to either of those two might be easier.

[armijnhemel]

Personally I would not mind having a small utility that can easily convert between the two, just for sanity checking.

[vcunat]

@armijnhemel: we've always had that. Example:

$ nix-hash --type sha256 --to-base32 bbce1b18733dd7ab17bf59d50bdce274b6cb1a1a55f1ceee6d7d4b3cda631f43
0hqzcgd3qjvxdppcxwam38dcpdklwbf0pmarpwbspmrxfcc1pkmv

[armijnhemel]

Not always! I remember that not being there back in the day ;-)

[pequalsmp]

Feel free to ignore my ignorance, but as i started experimenting with Nix this was one of the things that stood out to me.

This field is misleading as it doesn't contain a sha256 hash, it contains a base32-encoded sha256 hash. Perhaps, just hash or nixhash?

Is base32 being used to reduce the string length? Because hashes are already [0-9][a-f], thus base32/48/64 encoding doesn't improve readability/compatibility.

[edolstra]

Well, a SHA-256 hash is a sequence of bytes, not a sequence of a hexadecimal digits. A base32 encoding of it is no less real than a base16 encoding.

Yes, base32 was primarily used to reduce string lengths. Note that Nix 2.2 adds SRI hashes, which have the advantage of being standard and even shorter (because they use base64). For example,

import <nix/fetchurl.nix> {
  url = https://nixos.org/releases/nix/nix-2.1.3/nix-2.1.3.tar.xz;
  hash = "sha256-XSLa0FjVyADWWhFfkZ2iKTjFDda6mMXjoYMXLRSYQKQ=";
}

I'll close this issue because the solution to the confusion is to use SRI hashes everywhere in the future.