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