php's parse_url does not handle proper rfc3986 URIs, specifically, it does not handle the case of an empty authority such as file:/// or local:/// and only handles the case of file by applying a special case for file itself. These URIs are deemed "malformed" and return false. When such URIs were used, we would end up always treating the package source as a filename (despite that this is incorrect, since plain files will be correctly handled by parse_url, we will correctly determine that there is no schema, and we will go to the source_file_uri). Instead, handle the case of a "malformed" URI by treating it as another example of a source with a schema, and linking it as-is. See https://lists.archlinux.org/pipermail/aur-general/2019-January/034782.html for details. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> --- This fixes the case of local:///, but are there other cases where php would claim a malformed url where we would actually want to link to cgit? Should we just be dumb like makepkg and git/update.py, and check if it has the string literal '://'? Given the other two places where a source url might be handled don't even make a pretense of being proper rfc3986 parsers, this would at least mean we're highly consistent in our behavior. web/lib/pkgfuncs.inc.php | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/web/lib/pkgfuncs.inc.php b/web/lib/pkgfuncs.inc.php index ced1f8e..126b5c3 100644 --- a/web/lib/pkgfuncs.inc.php +++ b/web/lib/pkgfuncs.inc.php @@ -481,7 +481,7 @@ function pkg_source_link($url, $arch, $package) { $url = explode('::', $url); $parsed_url = parse_url($url[0]); - if (isset($parsed_url['scheme']) || isset($url[1])) { + if ($parsed_url === false || isset($parsed_url['scheme']) || isset($url[1])) { $link = '<a href="' . htmlspecialchars((isset($url[1]) ? $url[1] : $url[0]), ENT_QUOTES) . '">' . htmlspecialchars($url[0]) . '</a>'; } else { $file_url = sprintf(config_get('options', 'source_file_uri'), htmlspecialchars($url[0]), $package); -- 2.20.1