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
Task Type Bug Report
Category makepkg
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 5.1.1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

makepkg 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.

Loading...