Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#61449 - makepkg incorrectly lexes URIs from PKGBUILD source array
Attached to Project:
Pacman
Opened by Jeremy Audet (ichimonji10) - Friday, 18 January 2019, 03:12 GMT
Opened by Jeremy Audet (ichimonji10) - Friday, 18 January 2019, 03:12 GMT
|
Detailsmakepkg assumes that all URIs within a PKGBUILD's source array will
contain the following string:: :// This is an easy assumption to make, but it's not actually true. `RFC 3986`_ states that in general, the only components of a URI which are required are the scheme and path, and the path may be an empty string. Consequently, for a generic scheme "foo," the following is valid:: foo: Specific schemes may further restrict the syntax. For example, the file scheme (`RFC 8089`_) states that: 1. The authority (i.e. hostname) may be omitted. 2. If the authority is omitted, the preceding // may be omitted. 3. The the path must be absolute. As a result, the following URIs are all equivalent and valid:: file://localhost/ file:/// file:/ This URI is invalid because of rules 1 and 2:: file:localhost/ These URIs are invalid because of rule 3:: file://localhost file:// file: makepkg could ignore these semantic rules with the excuse that "it only supports a specific subset of all URIs." And this is true. It supports the following [1]_:: * bzr * file * git * hg * local (not well recognized) * svn Notice, however, that "file" is one of the supported schemes. Thus, makepkg should support URIs that do *not* contain the string ``://``. ---- Should this bug be picked up, some other questionable aspects of makepkg's URI handling will undoubtedly be encountered. Consider the undocumented [2] local: scheme. These are valid and equivalent:: local://some-file local:///some-file But why? What is the meaning of the leading slashes? Assuming the local scheme can only reference files in the same directory as a PKGBUILD, then the leading slashes serve no semantic purpose. One could handle this by overhauling the handling of the local: scheme, deprecating leading slashes, and banning subsequent slashes:: local://some-file # warning about leading slashes local:sources/some-file # error ---- I've attached an archive containing some PKGBUILDs and associated files, where they demonstrate some of makepkg's behaviour. .. [1] See pacman source code, ``scripts/libmakepkg/source/``. .. [2] https://bugs.archlinux.org/task/61294 .. _RFC 3986: https://tools.ietf.org/html/rfc3986 .. _RFC 8089: https://tools.ietf.org/html/rfc8089 |
This task depends upon
Comment by Allan McRae (Allan) -
Friday, 18 January 2019, 03:58 GMT
I think we will just document that URIs must contain the authority sigil - '//'.
Comment by Jeremy Audet (ichimonji10) -
Friday, 18 January 2019, 18:19 GMT
If the worry is "this will be hard to implement," note that RFC 3986 provides a regex for lexing URIs in appendix B. AFAICT, it's written to sh syntax. See the attached script and https://tools.ietf.org/html/rfc3986#appendix-B
Comment by Jeremy Audet (ichimonji10) -
Saturday, 19 January 2019, 19:00 GMT
If the concern is "this is too low priority for anyone on the team to work on," then I'm happy to take a stab at writing a patch. However, it'd be nice to know whether such a patch would be considered before I invest time into developing said patch.
arch-pkgs.tar.xz
regex-demo.sh
(0.7 KiB)