You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way Nimble reads project info currently is broken. It depends on the iteration order of packages in ~/.nimble/pkgs2, which include packages from any URL.
This should be useful, but unfortunately the package caching and URL handling doesn't account for this. Also, it depends on the Nimble commands used and refactors could changes the behavior of commands as well.
This issue can also occur even if an upstream dependency uses a URL for requires "url". In that way a bad actor could trick your local Nimble to install their package and modify their project checksum so it'll be loaded first.
This is a concrete example showing what happens based on #1323
Stage 1
My project Figuro uses windy. We do a nimble install -d and get:
I decide to abandon the feature, or it gets merged upstream but without a new release, etc. Lots of variations can occur.
We revert figuro.nimble back to requires "windy". We expect Nimble would go back to the official Windy package right?
Nope! Worse is that behavior seems to depend on the checksum hash as that's the order that Nimble will load the package info. In this case it appears to be choosing the last package repo which is my forked package.
It sticks with the forked version even if we do a nimble install -d again:
Bonus Issue - Let the compiler decide which package it uses
It seems like this would occur even with the same URL / official repo as well since every branch also gets added to the mix. Having versions wouldn't fix this either as long as two branchs/forks/urls exist with the same version.
The way Nimble reads project info currently is broken. It depends on the iteration order of packages in
~/.nimble/pkgs2
, which include packages from any URL.This should be useful, but unfortunately the package caching and URL handling doesn't account for this. Also, it depends on the Nimble commands used and refactors could changes the behavior of commands as well.
This issue can also occur even if an upstream dependency uses a URL for
requires "url"
. In that way a bad actor could trick your local Nimble to install their package and modify their project checksum so it'll be loaded first.This is a concrete example showing what happens based on #1323
Stage 1
My project Figuro uses
windy
. We do animble install -d
and get:Step 2
I fork windy and test out a new feature at https://github.com/elcritch/windy#macos-keyinput-fixes.
Running
nimble install -d
works as expected and we get:Step 3
I decide to abandon the feature, or it gets merged upstream but without a new release, etc. Lots of variations can occur.
We revert
figuro.nimble
back torequires "windy"
. We expect Nimble would go back to the official Windy package right?Nope! Worse is that behavior seems to depend on the checksum hash as that's the order that Nimble will load the package info. In this case it appears to be choosing the last package repo which is my forked package.
It sticks with the forked version even if we do a
nimble install -d
again:Bonus Issue - Let the compiler decide which package it uses
Adding this to figuro.nimble like:
Results in this:
Which means on the Nimble commands used, the Nim compiler could get multiple paths for the same package name "windy". I'm not sure what happens then.
The text was updated successfully, but these errors were encountered: