apk-tools 2.14.3 fails to parse APKs with more than 3 gzip members
We (wolfi) used to build APKs where the package data was (accidentally) split into multiple gzip members.
Older version of apk-tools handled this and did not complain, but apk-tools 2.14.3 (I have not tested any other patch versions) fails with BAD archive
.
$ cat /etc/apk/repositories
https://packages.wolfi.dev/os
https://dl-cdn.alpinelinux.org/alpine/v3.19/main
https://dl-cdn.alpinelinux.org/alpine/v3.19/community
$ wget -P /etc/apk/keys https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
$ apk -h | head-n1
apk-tools 2.14.3, compiled for aarch64.
$ apk add autoconf-archive
(1/1) Installing autoconf-archive (2023.02.20-r0)
ERROR: Failed to create usr/share/aclocal/ax_create_stdint_h.m4: Bad message
ERROR: autoconf-archive-2023.02.20-r0: BAD archive
$ curl -sL https://packages.wolfi.dev/os/aarch64/autoconf-archive-2023.02.20-r0.apk | xxd -s 144163 -l 4
00023323: 1f8b 0800
The fourth gzip member begins at 144163, which corresponds to the uncompressed offset 1050624, which happens to be in the middle of the usr/share/aclocal/ax_create_stdint_h.m4
file, which leads me to believe that apk-tools now expects there to be exactly 3 gzip members in an APK and will fail if the third member ends before the end of the archive.
We no longer build packages that exhibit this behavior, so this isn't a huge deal, but any of our packages that haven't been rebuilt in a long time can't be installed with apk
now. I would not be surprised if this issue is closed as "working as intended", but I wanted to document the regression.