FS#64195 - Corrupted packages in Arch Linux Archive

Attached to Project: Arch Linux
Opened by David (dlo9) - Sunday, 20 October 2019, 21:01 GMT
Last edited by Jelle van der Waa (jelly) - Monday, 18 September 2023, 18:01 GMT
Task Type Bug Report
Category Mirrors
Status Closed
Assigned To Jelle van der Waa (jelly)
Sven-Hendrik Haase (Svenstaro)
freswa (frederik)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This bug has the same fact pattern as in bug #64145 (https://bugs.archlinux.org/task/64145) -- that is, there are some corrupted packages in the Arch Linux Archive (ALA).

These are the packages:
python2-zbar
virglrenderer
zbar-gtk
zbar-qt

Here are details for each package from the ALA and various mirrors (columns are MD5, local filename, package size, URL). In each case, the ALA package is corrupted under dates snapshots and packages/<letter>/<pkg name> paths, but not under the `last` snapshot path, which appears to be an up-to-date mirror.

987a76296083b7e23d8ef1e8cec6f556 python2-zbar.ala 170776 https://archive.archlinux.org/packages/p/python2-zbar/python2-zbar-0.23-1-x86_64.pkg.tar.xz
7d978e5a6f684f84dbf5836201dd9bb7 python2-zbar.ala_last 170572 https://archive.archlinux.org/repos/last/extra/os/x86_64/python2-zbar-0.23-1-x86_64.pkg.tar.xz
987a76296083b7e23d8ef1e8cec6f556 python2-zbar.ala_dated 170776 https://archive.archlinux.org/repos/2019/10/19/extra/os/x86_64/python2-zbar-0.23-1-x86_64.pkg.tar.xz
7d978e5a6f684f84dbf5836201dd9bb7 python2-zbar.ala_mirror 170572 rsync://polymorf.fr/archlinux/extra/os/x86_64/python2-zbar-0.23-1-x86_64.pkg.tar.xz
7d978e5a6f684f84dbf5836201dd9bb7 python2-zbar.mirror 170572 https://www.archlinux.org/packages/extra/x86_64/python2-zbar/download/

d03315706432b60853d0422ef758e0ea virglrenderer.ala 195888 https://archive.archlinux.org/packages/v/virglrenderer/virglrenderer-0.8.0-1-x86_64.pkg.tar.xz
60032fcdc0122783c4335994fda54704 virglrenderer.ala_last 195752 https://archive.archlinux.org/repos/last/extra/os/x86_64/virglrenderer-0.8.0-1-x86_64.pkg.tar.xz
d03315706432b60853d0422ef758e0ea virglrenderer.ala_dated 195888 https://archive.archlinux.org/repos/2019/10/19/extra/os/x86_64/virglrenderer-0.8.0-1-x86_64.pkg.tar.xz
60032fcdc0122783c4335994fda54704 virglrenderer.ala_mirror 195752 rsync://polymorf.fr/archlinux/extra/os/x86_64/virglrenderer-0.8.0-1-x86_64.pkg.tar.xz
60032fcdc0122783c4335994fda54704 virglrenderer.mirror 195752 https://www.archlinux.org/packages/extra/x86_64/virglrenderer/download/

88f06aed75e988d02b5fe0608dd2d9cb zbar-gtk.ala 17940 https://archive.archlinux.org/packages/z/zbar-gtk/zbar-gtk-0.23-1-x86_64.pkg.tar.xz
e9446b0000544fd39a8d999fc75c0d45 zbar-gtk.ala_last 17920 https://archive.archlinux.org/repos/last/extra/os/x86_64/zbar-gtk-0.23-1-x86_64.pkg.tar.xz
88f06aed75e988d02b5fe0608dd2d9cb zbar-gtk.ala_dated 17940 https://archive.archlinux.org/repos/2019/10/19/extra/os/x86_64/zbar-gtk-0.23-1-x86_64.pkg.tar.xz
e9446b0000544fd39a8d999fc75c0d45 zbar-gtk.ala_mirror 17920 rsync://polymorf.fr/archlinux/extra/os/x86_64/zbar-gtk-0.23-1-x86_64.pkg.tar.xz
e9446b0000544fd39a8d999fc75c0d45 zbar-gtk.mirror 17920 https://www.archlinux.org/packages/extra/x86_64/zbar-gtk/download/

79b050d88ccb543bf9ad7f84dfebf74a zbar-qt.ala 57220 https://archive.archlinux.org/packages/z/zbar-qt/zbar-qt-0.23-1-x86_64.pkg.tar.xz
261c8b501a6cb8b80c58c16c32998617 zbar-qt.ala_last 55540 https://archive.archlinux.org/repos/last/extra/os/x86_64/zbar-qt-0.23-1-x86_64.pkg.tar.xz
79b050d88ccb543bf9ad7f84dfebf74a zbar-qt.ala_dated 57220 https://archive.archlinux.org/repos/2019/10/19/extra/os/x86_64/zbar-qt-0.23-1-x86_64.pkg.tar.xz
261c8b501a6cb8b80c58c16c32998617 zbar-qt.ala_mirror 55540 rsync://polymorf.fr/archlinux/extra/os/x86_64/zbar-qt-0.23-1-x86_64.pkg.tar.xz
261c8b501a6cb8b80c58c16c32998617 zbar-qt.mirror 55540 https://www.archlinux.org/packages/extra/x86_64/zbar-qt/download/
This task depends upon

Closed by  Jelle van der Waa (jelly)
Monday, 18 September 2023, 18:01 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/a rch-mirrors/issues/1
Comment by Florian Pritz (bluewind) - Friday, 25 October 2019, 11:18 GMT
The URLs with the broken checksum are redirected to archive.org. The repos/last/ URL does not match the regex[1] we use for the redirect and is thus served by our server directly.

[1] https://git.archlinux.org/infrastructure.git/tree/roles/archive/templates/nginx.d.conf.j2#n39

The script that uploads files to archive.org is located here[2] and you are welcome to adapt it to include the filesize/modification time to detect changed files and reupload them.

[2] https://github.com/archlinux/arch-historical-archive

I have removed the 4 packages in question from the database kept by the uploader so that they have been reuploaded now. I will keep this bug open if you or someone else wishes to improve the uploader script, but the 4 packages should be fixed now.
Comment by David (dlo9) - Sunday, 27 October 2019, 21:41 GMT
Thanks! I'll take a look at the script in the coming weeks when I find the time if no one else has made the changes by then.
Comment by Eli Schwartz (eschwartz) - Wednesday, 30 October 2019, 01:21 GMT
What I do not understand is, how can the files be getting updated at all? The archive should not allow this.

Were these packages rebuilt and db-updated without a pkgrel bump? This is the same issue as a recent mesa issue. Packagers should not be recreating a package, since it breaks pacman's download cache as well. It also causes downstream projects, such as Parabola which syncs our repos but drops some packages and rebuilds some others to remove 'libre' issues, to see outdated versions of the package (they sync the first one, but don't notice the file has changed in-place) to continue serving the old version -- and in the case of mesa, that replaced version contained a bunch of bugfixes and a different filelist.

"detecting changed files and reuploading them" is just replacing one form of brokenness with another, if we treat both of those files the same then one or the other $repo.db is going to always be wrong, and re-uploading the file just changes which .db is the corrupt one.

Before the archive.org uploader, we never noticed this due to I suspect the fact that only identical files were hardlinked, so the repository paths were always correct due to serving different files (the correct one for each date). The new redirection logic just matches filenames without directory paths...
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

Loading...