Redirects not properly stored in flake.lock

[mkg20001]

Describe the bug

When using an url that redirects to "the latest" version of a particular flake, then instead of storing the final url nix will store the url it originally started to download from

That url might return a different file later thus breaking the lockfile

It should store the final url instead, to ensure it will always get the same file

Steps To Reproduce

1. git clone https://gist.github.com/mkg20001/4581e1beb3cd5cdca01558e0504f4335 gist
2. cd gist
3. nix flake update

(URL used was https://channels.nixos.org/nixpkgs-unstable/nixexprs.tar.xz but anything that redirects breaks)

Expected behavior

flake.lock nodes.nixpkgs.locked.url is equal to final url that the download redirected to

nix-env --version output nix-env (Nix) 2.4pre20210922_bcd73eb, /nix/store/pp4s6sjyx73n1jrfrfmgpvkyl3s2ppyk-nix-2.4pre20210922_bcd73eb/bin/nix

Additional context

[tomprince]

I was definitely hoping that nix had the behaviour described as above (for exactly the same family as URLs as used in the example).

That said, it wouldn't surprise me if this is something that needs to be configurable per-input. Two possible cases that occur to me where the above behaviour wouldn't be desired:

• A redirect to a time-limited URL (such as an s3 presigned URL)
• A redirect to (possibly geo-ip based) mirror

[stale[bot]]

I marked this as stale due to inactivity. → More info

[emilazy]

Perhaps the original URL could be retried in case the locked post‐redirects URL fails? That could avoid the need for configuration while still allowing easy pinning in most cases. Since the hash will still be checked, the potential damage is limited.

[Zocker1999NET]

Perhaps the original URL could be retried in case the locked post‐redirects URL fails? That could avoid the need for configuration while still allowing easy pinning in most cases.

This sounds to me as a good compromise to avoid manual reconfiguration, especially because

Since the hash will still be checked, the potential damage is limited.

My ideas to make this approach more resilient:

• allow to store multiple URLs to potentially store the whole redirection chain
  • because multiple redirects might be stacked
• but do not store URLs which issued an immediate redirect (HTTP response status codes 301 & 308)
  • to avoid hitting a URL which might cease in the future
  • (bonus, if easily possible) warn user if the flake directly contains an URL pointing to a permanent redirect
• when processing a lock entry with multiple URLs to download stuff, try them in the same order
  • in case another CDN is better for your current location
• add an option to nix (& make it configurable from a flake by default) which allows excluding URLs from a redirection pattern
  • should be regex / glob / etc., so that an entry could e.g. be *.amazonaws.com
  • a (Geo-)IP based redirects might reveal the location of the original user
  • this should no be no big problem in general because users do (hopefully) read what they commit
  • but this can give an easy way to avoid such URLs being written to the lock file by nix