Pacman

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

FS#36813 - pacman should reject HTTP 300 responses

Attached to Project: Pacman
Opened by Eric Rannaud (eric.rannaud) - Friday, 06 September 2013, 20:24 GMT
Last edited by Dave Reisner (falconindy) - Friday, 06 September 2013, 20:40 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.1.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:

The mirror mirrors.aggregate.org doesn't return 404 when a particular package version is missing, instead it returns a "300 Multiple Choices" webpage. pacman accepts the HTML content and tries to verify its signature, which of course fails.

pacman should reject the content returned by a 300 response and go to the next mirror.

Steps to Reproduce:

# With a likely quite stale database (I haven't updated it recently), I did
pacman -S cpupower

# To get such a 300 HTTP response:
curl http://mirrors.aggregate.org/archlinux/community/os/x86_64/cpupower-3.10-2-x86_64.pkg.tar.xz

Workaround:

pacman -Sy
pacman -S cpupower
This task depends upon

Closed by  Dave Reisner (falconindy)
Friday, 06 September 2013, 20:40 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Broken mirror. See  FS#36815 
Comment by Dave Reisner (falconindy) - Friday, 06 September 2013, 20:33 GMT
There's nothing that pacman can (or will) do with a 300 response -- the redirects are in the body.

This is a mirror issue. I'm not interested in fixing this in pacman.
Comment by Eric Rannaud (eric.rannaud) - Friday, 06 September 2013, 21:58 GMT
I'm not suggesting the multiple options redirect be handled, quite the opposite. As you say, there is nothing that pacman can do to use a 300 response.

However, pacman currently *accepts* such a response and handles the HTML data (that you copied in  FS#36815 ) as if it were a package file, and that fails, and pacman exits without completing the transaction, displaying a scary message about corrupted package or invalid signature.

Instead, I'd argue, pacman should treat a 300 effectively like a response >= 400, delete the downloaded file and skip the mirror. Something like the patch in attachment?

Thanks.
   pacman-dload-300-is-error.pat... (0.5 KiB)
Comment by Dan McGee (toofishes) - Friday, 06 September 2013, 22:59 GMT
It's an odd special case, but I'm not against adding this to at least fail more gracefully. Dave- does curl handle the redirects for us? Should we just fail on anything >= 300 instead of 400, outside of a 304 Not Modified response?
Comment by Dave Reisner (falconindy) - Saturday, 07 September 2013, 00:17 GMT
Yes, curl generally handles redirects (we set CURLOPT_FOLLOWLOCATION). Notice that the real problem here is that the versions don't match. The "user" requested version 3.10-2 and received an offer of 3.11-1.

RFC2616 is pretty vague about how this is generally handled:

---------8<-------------------
Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of

the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.
--------->8-------------------

I guess the proposed patch is the "best" thing we can do here, as odd as the behavior is. It isn't much different from failing on >=300 except for a 304, since there isn't a whole lot defined in the HTTP3xx range.

Loading...