aboutsummaryrefslogtreecommitdiff
path: root/src/libutil/url.cc
AgeCommit message (Collapse)Author
2024-08-04tree-wide: fix various lint warningsJade Lovelace
Change-Id: I0fc80718eb7e02d84cc4b5d5deec4c0f41116134
2024-06-29Reject fully-qualified URLs in 'from' argument of `nix registry add`Delan Azabani
We previously allowed you to map any flake URL to any other flake URL, including shorthand flakerefs, indirect flake URLs like `flake:nixpkgs`, direct flake URLs like `github:NixOS/nixpkgs`, or local paths. But flake registry entries mapping from direct flake URLs often come from swapping the 'from' and 'to' arguments by accident, and even when created intentionally, they may not actually work correctly. This patch rejects those URLs (and fully-qualified flake: URLs), making it harder to swap the arguments by accident. Fixes #181. Change-Id: I24713643a534166c052719b8770a4edfcfdb8cf3
2024-05-29util.{hh,cc}: Split out strings.{hh,cc}Tom Hubrecht
Change-Id: I4f642d1046d56b5db26f1b0296ee16a0e02d444a
2024-04-30implement parsing human-readable names from URLsQyriad
Based off of commit 257b768436a0e8ab7887f9b790c5b92a7fe51ef5 Upstream-PR: https://github.com/NixOS/nix/pull/8678 Co-authored-by: Felix Uhl <felix.uhl@outlook.com> Change-Id: Idcb7f6191ca3310ef9dc854197f7798260c3f71d
2023-08-17libutil: fix double-encoding of URLsCole Helbling
If you have a URL that needs to be percent-encoded, such as `http://localhost:8181/test/+3d.tar.gz`, and try to lock that in a Nix flake such as the following: { inputs.test = { url = "http://localhost:8181/test/+3d.tar.gz"; flake = false; }; outputs = { test, ... }: { t = builtins.readFile test; }; } running `nix flake metadata` shows that the input URL has been incorrectly double-encoded (despite the flake.lock being correctly encoded only once): [...snip...] Inputs: └───test: http://localhost:8181/test/%252B3d.tar.gz?narHash=sha256-EFUdrtf6Rn0LWIJufrmg8q99aT3jGfLvd1//zaJEufY%3D (Notice the `%252B`? That's just `%2B` but percent-encoded again) With this patch, the double-encoding is gone; running `nix flake metadata` will show the proper URL: [...snip...] Inputs: └───test: http://localhost:8181/test/%2B3d.tar.gz?narHash=sha256-EFUdrtf6Rn0LWIJufrmg8q99aT3jGfLvd1//zaJEufY%3D --- As far as I can tell, this happens because Nix already percent-encodes the URL and stores this as the value of `inputs.asdf.url`. However, when Nix later tries to read this out of the eval state as a string (via `getStrAttr`), it has to run it through `parseURL` again to get the `ParsedURL` structure. Now, this itself isn't a problem -- the true problem arises when using `ParsedURL::to_string` later, which then _re-escapes the path_. It is at this point that what would have been `%2B` (`+`) becomes `%252B` (`%2B`).
2023-02-27url: make percentEncode stricter, expose and unit test itYorick van Pelt
2023-01-20Fix url parsing for urls using `file+`Eric Wolf
`file+https://example.org/test.mp4` should not be rejected with `unexpected authority`.
2022-05-19fetchTree: Allow fetching plain filesTony Olagbaiye
Add a new `file` fetcher type, which will fetch a plain file over http(s), or from the local file. Because plain `http(s)://` or `file://` urls can already correspond to `tarball` inputs (if the path ends-up with a know archive extension), the URL parsing logic is a bit convuluted in that: - {http,https,file}:// urls will be interpreted as either a tarball or a file input, depending on the extensions of the path part (so `https://foo.com/bar` will be a `file` input and `https://foo.com/bar.tar.gz` as a `tarball` input) - `file+{something}://` urls will be interpreted as `file` urls (with the `file+` part removed) - `tarball+{something}://` urls will be interpreted as `tarball` urls (with the `tarball+` part removed) Fix #3785 Co-Authored-By: Tony Olagbaiye <me@fron.io>
2021-07-01Prefer to throw specific errorsPamplemousse
Signed-off-by: Pamplemousse <xav.maso@gmail.com>
2020-09-21Don't include <regex> in header filesEelco Dolstra
This reduces compilation time by ~15 seconds (CPU time). Issue #4045.
2020-05-30Improve ref validity checking in fetchGitNikola Knezevic
The previous regex was too strict and did not match what git was allowing. It could lead to `fetchGit` not accepting valid branch names, even though they exist in a repository (for example, branch names containing `/`, which are pretty standard, like `release/1.0` branches). The new regex defines what a branch name should **NOT** contain. It takes the definitions from `refs.c` in https://github.com/git/git and `git help check-ref-format` pages. This change also introduces a test for ref name validity checking, which compares the result from Nix with the result of `git check-ref-format --branch`.
2020-04-07Backport libfetchers from the flakes branchEelco Dolstra
This provides a pluggable mechanism for defining new fetchers. It adds a builtin function 'fetchTree' that generalizes existing fetchers like 'fetchGit', 'fetchMercurial' and 'fetchTarball'. 'fetchTree' takes a set of attributes, e.g. fetchTree { type = "git"; url = "https://example.org/repo.git"; ref = "some-branch"; rev = "abcdef..."; } The existing fetchers are just wrappers around this. Note that the input attributes to fetchTree are the same as flake input specifications and flake lock file entries. All fetchers share a common cache stored in ~/.cache/nix/fetcher-cache-v1.sqlite. This replaces the ad hoc caching mechanisms in fetchGit and download.cc (e.g. ~/.cache/nix/{tarballs,git-revs*}). This also adds support for Git worktrees (c169ea59049f861aaba429f48b828d0820b74d1d).