Arch Linux

For my records, this is an example of a server that fails:

[linux-nitrous]
Server = https://github.com/xdevs23/linux-nitrous/releases/latest/download/


$ wget https://github.com/xdevs23/linux-nitrous/releases/latest/download/linux-nitrous.db
--2021-06-07 14:43:38-- https://github.com/xdevs23/linux-nitrous/releases/latest/download/linux-nitrous.db
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving github.com (github.com)... 52.64.108.95
Connecting to github.com (github.com)|52.64.108.95|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github.com/xdevs23/linux-nitrous/releases/download/v5.12.9-1/linux-nitrous.db [following]
--2021-06-07 14:43:38-- https://github.com/xdevs23/linux-nitrous/releases/download/v5.12.9-1/linux-nitrous.db
Reusing existing connection to github.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://github-releases.githubusercontent.com/219786970/e245c700-c49f-11eb-9996-6ede9f1acbf9?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210607%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210607T044339Z&X-Amz-Expires=300&X-Amz-Signature=dd5f350f470c339ced9e6133dc30618a5af8f3e84e4eb2e865358856c5aedbfd&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=219786970&response-content-disposition=attachment%3B%20filename%3Dlinux-nitrous.db&response-content-type=application%2Foctet-stream [following]
--2021-06-07 14:43:39-- https://github-releases.githubusercontent.com/219786970/e245c700-c49f-11eb-9996-6ede9f1acbf9?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210607%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210607T044339Z&X-Amz-Expires=300&X-Amz-Signature=dd5f350f470c339ced9e6133dc30618a5af8f3e84e4eb2e865358856c5aedbfd&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=219786970&response-content-disposition=attachment%3B%20filename%3Dlinux-nitrous.db&response-content-type=application%2Foctet-stream
Resolving github-releases.githubusercontent.com (github-releases.githubusercontent.com)... 185.199.108.154, 185.199.109.154, 185.199.111.154, ...
Connecting to github-releases.githubusercontent.com (github-releases.githubusercontent.com)|185.199.108.154|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5047 (4.9K) [application/octet-stream]
Saving to: ‘linux-nitrous.db’


And then we just put .sig on the end of that redirect to try getting the .sig file.


I wonder what pacman-5.2 did...

in pacman 5.2:

debug: url: https://github.com/xdevs23/linux-nitrous/releases/latest/download/linux-nitrous.db
debug: maxsize: 134217728
debug: opened tempfile for download: /var/lib/pacman/sync/linux-nitrous.db.part (wb)
downloading linux-nitrous.db...
debug: curl returned error 0 from transfer
debug: response code: 200
debug: url: https://github.com/xdevs23/linux-nitrous/releases/latest/download/linux-nitrous.db.sig
debug: maxsize: 16384
debug: opened tempfile for download: /var/lib/pacman/sync/linux-nitrous.db.sig.part (wb)
downloading linux-nitrous.db.sig...
debug: curl returned error 0 from transfer
debug: response code: 200


01:04 AM <agregory> we used to use only use the redirect url if it still ended in .db

Package .sig files are also affected: https://github.com/msys2/msys2-pacman/issues/1

https://git.archlinux.org/pacman.git/tree/lib/libalpm/dload.c?id=v6.0.0#n610

This should only use effective_url if trust_remote_name is enabled, if at all. Is that even desired or should the redirections always be retried?

This codepath did not exist in pacman 5.2, the signature was requested in another location, using payload->servers and payload->filepath:
https://git.archlinux.org/pacman.git/commit/?id=f078c2d3bcb72bafda0dce

At minimum this should use payload->fileurl if trust_remote_name is not set.
I think the old code also allowed to download the database from one mirror and the signature from another. The new code does not allow that anymore, but I do not know if that is desired.

I should probably have tested 6.0 before it came out so this could've been caught earlier.
Either way I'm happy this got attention. I can confirm this bug (did not happen with 5.2.2).