libutils/hash: remove default encoding #3655
Conversation
zimbatm
force-pushed
the
hash-encoding-prepare
branch
from
2521010
to
4bc53c7
Compare
This will make it easier to reason about the hash encoding and switch to SRI everywhere where possible.
zimbatm
force-pushed
the
hash-encoding-prepare
branch
from
4bc53c7
to
6ee03b8
Compare
|
For step 2, I would rather have #3453 merged first, as I think that opens the door to more renaming choices, but I still like the idea (and am fine about breakage with any other PR @matthewbauer and I have open, we can fix those). For step 3...part of me just doesn't like storing extra information that is only used for diagnostics, but I certainly am sympathetic to the use case. Maybe we could have separate a |
|
I like your idea of splitting Hash and HashWithEncoding. Then only HashWithEncoding would have an argument-less to_string() |
to_string(Base32, false);
to_string(SRI, true);I lack the insight to make any comments on broader design choices here but I think it would be great if if to_string(Base32, HashFormat::Plain);
to_string(SRI, HashFormat::TypePrefix); |
|
With the introduction of SRI, (SRI, false) doesn't make any sense. That's why I am proposing to change the API to be |
|
@zimbatm okay cool. I don’t know what SRI stands for by the way 😅 |
|
It stands for Subresource Integrity and is a standard from the w3c: https://www.w3.org/TR/SRI/ |
Compress the (Base, usePrefix) tuple to a single field that represents the hash encoding. This makes more sense because SRI always has a prefix. This is a continuation of the work started at NixOS#3655
Compress the (Base, usePrefix) tuple to a single field that represents the hash encoding. This makes more sense because SRI always has a prefix. This is a continuation of the work started at NixOS#3655
Compress the (Base, usePrefix) tuple to a single field that represents the hash encoding. This makes more sense because SRI always has a prefix. This is a continuation of the work started at NixOS#3655
Compress the (Base, usePrefix) tuple to a single field that represents the hash encoding. This makes more sense because SRI always has a prefix. This is a continuation of the work started at NixOS#3655
Compress the (Base, usePrefix) tuple to a single field that represents the hash encoding. This makes more sense because SRI always has a prefix. This is a continuation of the work started at NixOS#3655
Compress the (Base, usePrefix) tuple to a single field that represents the hash encoding. This makes more sense because SRI always has a prefix. This is a continuation of the work started at NixOS#3655
Compress the (Base, usePrefix) tuple to a single field that represents the hash encoding. This makes more sense because SRI always has a prefix. This is a continuation of the work started at NixOS#3655
This is the first step in a series of patches.
The idea, in the end, is that it will be possible to display the hash using the original encoding. This is to solve the issue where "expect got " is printed in a different encoding than what is in the source code. This makes it harder to scan the source to replace the hash.
hash.to_string()function but that prints using the original encoding. Remove the encoding from places where we want to show the original hash./cc @Ericson2314 @matthewbauer who have conflicting PRs open