[pacman-dev] [PATCH] libalpm: prevent 301 redirect loop from hanging the process

[Dave Reisner]

On Wed, Feb 06, 2019 at 05:22:46AM -0600, Mark Ulrich wrote:
> If a mirror responds with a 301 redirect to itself, it will create an
> infinite redirect loop. This will cause pacman to hang, unresponsive to
> even a SIGINT. The result is pacman being unable to sync or
> download any package from a particular repo if its current mirror
> is stuck in a redirect loop. Setting libcurl's MAXREDIRS option
> effectively prevents a redirect loop from hanging the process.
> 
> Signed-off-by: Mark Ulrich <mark.ulrich.86 at gmail.com>
> ---
>  lib/libalpm/dload.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
> index 36ae4ee1..d04a5e46 100644
> --- a/lib/libalpm/dload.c
> +++ b/lib/libalpm/dload.c
> @@ -259,6 +259,7 @@ static void curl_set_handle_opts(struct dload_payload *payload,
>  	curl_easy_setopt(curl, CURLOPT_URL, payload->fileurl);
>  	curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, error_buffer);
>  	curl_easy_setopt(curl, CURLOPT_CONNECTTIMEOUT, 10L);
> +	curl_easy_setopt(curl, CURLOPT_MAXREDIRS, 1L);

But what if you have a mirror which legitimately has 2 hops? I could see
someone trying to run something like:

  pacman -U https://www.archlinux.org/packages/core/x86_64/pacman/download/

This is guaranteed 1 redirect already, what if the mirror that it
redirects to has a legitimate second hop in order to account for some
reorganizing?

I'm fine with the spirit of the patch, but limiting this to a single hop
isn't enough. A larger number like 10 still accomplishes the same goal
while allowing some mirror flexibility/brokenness.

>  	curl_easy_setopt(curl, CURLOPT_FILETIME, 1L);
>  	curl_easy_setopt(curl, CURLOPT_NOPROGRESS, 0L);
>  	curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
> -- 
> 2.20.1