-
Notifications
You must be signed in to change notification settings - Fork 22
SHA256 hash mismatches (deno cache
and curl | sha256sum
disagree)
#27
Comments
There is a (lengthy) discussion of hash mismatches here which might be useful (and it's certainly extensive enough to suggest you're not the only one). |
It looks like esm.sh returns something different based on the User-Agent, so deno2nix should set it: https://mspsocial.net/users/ironiridis/statuses/109866537157919405 |
@fasterthanlime Note that my instance doesn't permit unauthenticated access due to an upstream Mastodon change so here's the text of that post:
This is in the context of Amos's post. |
I tried passing
|
Oh, this is a duplicate of #6! Closing. |
@fasterthanlime The reason it fails is because My changes: voidcontext@3f2577b |
@voidcontext Can you try |
@ironiridis Yes, I can try that a little bit later, but the problem is this:
And tha sha256sum in the lock file is |
@ironiridis yup, same issue with this: voidcontext@ab9ac6e |
|
This is kind of a weird problem. When
nix build
ing one of my projects withdeno2nix
, I get errors like:I'm not sure how those hashes are formatted (they don't look like hex, there's
w
in there), but out of curiosity, I checked what was indeno.lock
and compared it withcurl url | gsha256sum
, and they disagree:The deno.lock file has
2b8ec155eb8b87501663f074acff1d55a9114fa7d88f0b39da06c940af1ff736
, but:$ curl -s https://esm.sh/preact@10.11.0/hooks | gsha256sum 96fc4fa78b0fe58cf6bd72378f8e159fd198fdbbef5ece0c339150c3d0f13d11 -
This might be a bug in
deno cache
(1.30.3), oresm.sh
might be serving something different for different user-agents (and in this case it can be fixed indeno2nix
?). All I know right now is that it's weird and I'm wondering if you have any idea where this could come from.(My best idea of a workaround right now is to write a tool that updates
deno.lock
with the proper SHA256 sums before callingnix build
, but that's not great).The text was updated successfully, but these errors were encountered: