apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2024-03-08T14:45:39Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10875add PURL field to apkv3 package data2024-03-08T14:45:39ZAriadne Conillariadne@ariadne.spaceadd PURL field to apkv3 package dataSecurity scanners have issues with disambiguating distribution package names (which exist in a flat namespace) verses upstream package names. In Alpine, a notable example of this would be the lua packages, e.g. `lua5.1`, `lua5.2`, etc. ...Security scanners have issues with disambiguating distribution package names (which exist in a flat namespace) verses upstream package names. In Alpine, a notable example of this would be the lua packages, e.g. `lua5.1`, `lua5.2`, etc. In these cases, scanners are unable to deduce that `lua5.1` is equivalent to upstream `lua~5.1` (e.g. lua 5.1.x).
An emergent industry standard to allow for disambiguation is the [Package URL specification](https://github.com/package-url/purl-spec). We should store this data in APKs, to help the scanners disambiguate.
(This would also require us to add PURLs where needed in our package build recipes, e.g. aports et al. But this is out of scope for here.)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10874conversion of installeddb and query applets to new database format2023-01-31T11:16:53ZTimo Teräsconversion of installeddb and query applets to new database formatConvert all internal code to use the new ADB based structures.
Support old indexes by doing on-the-fly conversion.
Automatically convert and keep installeddb in the new format.Convert all internal code to use the new ADB based structures.
Support old indexes by doing on-the-fly conversion.
Automatically convert and keep installeddb in the new format.v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10873tooling for repository mirroring2023-04-11T17:55:40ZTimo Terästooling for repository mirroringImprove existing applets (e.g. `fetch`) or create new one(s) to allow for:
- downloading repository index and all packages in it
- support incremental download with modified-since timestamp (or possibly compared to an old index)
- rec...Improve existing applets (e.g. `fetch`) or create new one(s) to allow for:
- downloading repository index and all packages in it
- support incremental download with modified-since timestamp (or possibly compared to an old index)
- recreate repository index given index and list of directories where to look files from; create symlinks or hardlinks
- print list of package names present on indexv3.0Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10872Command apk add needs its time to return a non zero exit code2023-01-21T20:04:34ZPantelis KaramolegkosCommand apk add needs its time to return a non zero exit code`Dockerfile`
```Dockerfile
FROM alpine:3.16
WORKDIR /home/test
COPY script.sh /tmp/
RUN chmod +x /tmp/script.sh \
&& /tmp/script.sh \
&& rm -f /tmp/script.sh
```
`script.sh`
```bash
#!/bin/sh
apk update
wget -q -O /etc/apk/key...`Dockerfile`
```Dockerfile
FROM alpine:3.16
WORKDIR /home/test
COPY script.sh /tmp/
RUN chmod +x /tmp/script.sh \
&& /tmp/script.sh \
&& rm -f /tmp/script.sh
```
`script.sh`
```bash
#!/bin/sh
apk update
wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.32-r0/glibc-2.32-r0.apk
apk add glibc-2.32-r0.apk
sleep 1
```
`docker build -t test-image . --no-cache --progress=plain` will succeed.
If however one comments out `sleep 1` it will fail.
The error is always there in the `docker build` logs
```
#8 5.418 ERROR: glibc-2.32-r0: trying to overwrite etc/nsswitch.conf owned by alpine-baselayout-data-3.2.0-r23.
#8 5.490 1 error; 15 MiB in 15 packages
#8 DONE 6.6s
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10871[apk-tools] apk search [-d] is case sensitive by default2023-10-12T10:08:44ZJustin[apk-tools] apk search [-d] is case sensitive by defaultapk search [-d] is case sensitive by default, which i think is a **bug**. example:
`apk search -d ntp` will not find chrony, but `apk search -d NTP` will find it.
either turn off the case sensitive, or add an option to ignore case.apk search [-d] is case sensitive by default, which i think is a **bug**. example:
`apk search -d ntp` will not find chrony, but `apk search -d NTP` will find it.
either turn off the case sensitive, or add an option to ignore case.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10870Cannot install packages with symlinks to FAT32 filesystems2023-01-16T17:14:39ZPatrycja Rosaalpine@ptrcnull.meCannot install packages with symlinks to FAT32 filesystemsin my specific case, having EFI system partition mounted at `/boot` and installing a package like `main/xen-hypervisor` fails on `symlinkat("xen-4.17.0.gz", 3, "boot/.apk...") = -1 EPERM` called from [here][1]
*technically* that's not a...in my specific case, having EFI system partition mounted at `/boot` and installing a package like `main/xen-hypervisor` fails on `symlinkat("xen-4.17.0.gz", 3, "boot/.apk...") = -1 EPERM` called from [here][1]
*technically* that's not an issue with apk itself - the package literally has a symlink and apk is just trying to do its job - but it would be nice if there was some kind of a workaround for it (or maybe a more helpful error message)
[1]: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/v2.12.10/src/io_archive.c#L382https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10869Support for faster TCP/HTTP timeout on stale network2023-10-12T14:50:17ZCarlo DéSupport for faster TCP/HTTP timeout on stale networkHello,
It seems apk update, at least on alpine 3.16, has no timeout at all. When the targeted mirror is down, it just keeps trying to get the APKINDEX.tar.gz forever.
The man-page says the command has no option. If it is not feasible t...Hello,
It seems apk update, at least on alpine 3.16, has no timeout at all. When the targeted mirror is down, it just keeps trying to get the APKINDEX.tar.gz forever.
The man-page says the command has no option. If it is not feasible to add a "--timeout" option, would it be at least possible to set a decent internal timeout (< 5min)? As is, when the system's automatically upgraded during the boot, you end with a de facto frozen box.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10868add vendor field to apkv2/apkv3 control data and apkdb2024-03-08T14:45:39ZAriadne Conillariadne@ariadne.spaceadd vendor field to apkv2/apkv3 control data and apkdbSoftware component analysis tools (and related software such as vulnerability scanning tools) use CPE identifiers and Package URLs (PURLs) to determine the ecosystem a software component originates from.
At present, the apkdb does not c...Software component analysis tools (and related software such as vulnerability scanning tools) use CPE identifiers and Package URLs (PURLs) to determine the ecosystem a software component originates from.
At present, the apkdb does not contain this information, so SCA tools assume that all packages originate from the distribution. This causes problems when trying to understand the relationship between software components and their suppliers, to do things like find out about remediated CVEs, as the calculated CPE identifiers and PURLs are matched to the wrong supplier.
Since Alpine 3.16, we have shipped `/etc/secfixes.d/$vendorlabel`, e.g. `/etc/secfixes.d/alpine`, files in the baselayout. Some other apk distributions which use the same secdb format have done the same such as $dayjob's Wolfi GNU/Linux distribution. By providing a vendor tag in the APK control data and apkdb which matches to these `/etc/secfixes.d` files, we can correctly map relevant security remediation feeds to the packages.
I'm happy to work on this if @fabled agrees we should do this.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10867Documentation on cmd:PATTERN, so:PATTERN etc. missing from apk-search.82022-12-26T13:28:50ZPaul W. Rankinhello@paulwrankin.comDocumentation on cmd:PATTERN, so:PATTERN etc. missing from apk-search.8I'm not sure where I learnt that `apk-search(8)` could accept `cmd:PATTERN` but it seems it was not the man page.
Upon trying to learn which prefixes are available the documentation is missing.I'm not sure where I learnt that `apk-search(8)` could accept `cmd:PATTERN` but it seems it was not the man page.
Upon trying to learn which prefixes are available the documentation is missing.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10866Sort upgrade package list2023-02-14T13:05:31ZJustinSort upgrade package list```
The following packages will be upgraded:
cryptsetup-libs cryptsetup cryptsetup-openrc llvm15-libs libpng abuild tzdata wavpack appstream appstream-qt discover discover-backend-apk libpng-dev discover-lang appstream-lang clang15-lib...```
The following packages will be upgraded:
cryptsetup-libs cryptsetup cryptsetup-openrc llvm15-libs libpng abuild tzdata wavpack appstream appstream-qt discover discover-backend-apk libpng-dev discover-lang appstream-lang clang15-libclang kpipewire kpipewire-lang plasma-pa plasma-pa-lang
```
This is not that nice to try read if you're looking to see if a specific package has an upgrade available.
A sorted list would be better like
```
abuild
appstream
appstream-lang
appstream-qt
clang15-libclang
cryptsetup
cryptsetup-libs
cryptsetup-openrc
discover
discover-backend-apk
discover-lang
kpipewire
kpipewire-lang
libpng
libpng-dev
llvm15-libs
plasma-pa
plasma-pa-lang
tzdata
wavpack
```v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10865Add info on where each package in apk upgrade is coming from2022-12-21T18:56:12ZJustinAdd info on where each package in apk upgrade is coming fromIf the user has multiple repositories installed, show where each package is coming from.
For instance I have a script that does this with apt data and spits out this:
```
+------------------+-----------------+-------------------+------...If the user has multiple repositories installed, show where each package is coming from.
For instance I have a script that does this with apt data and spits out this:
```
+------------------+-----------------+-------------------+-------------------+
| Package Name | Repository | Current Version | New Version |
+------------------+-----------------+-------------------+-------------------+
| kpartx | focal-security | 0.8.3-1ubuntu2 | 0.8.3-1ubuntu2.1 |
| libexpat1 | focal-security | 2.2.9-1ubuntu0.4 | 2.2.9-1ubuntu0.5 |
| multipath-tools | focal-security | 0.8.3-1ubuntu2 | 0.8.3-1ubuntu2.1 |
+------------------+-----------------+-------------------+-------------------+
```v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10864apk-tool sort results of search2023-10-12T10:08:44ZJustinapk-tool sort results of searchapk search does not sort results in alphabetical order, user must either scour the list or pipe it to sort.apk search does not sort results in alphabetical order, user must either scour the list or pipe it to sort.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10863On two packages (gtk4.0-9999-r2, gtk+3.0-9999_git20210602-r2) `apk info` will...2022-12-21T19:19:35ZEllieOn two packages (gtk4.0-9999-r2, gtk+3.0-9999_git20210602-r2) `apk info` will just display nothingOn two packages (gtk4.0-9999-r2, gtk+3.0-9999_git20210602-r2) on postmarketOS, `apk info` and `apk policy` will just display nothing:
```
$ sudo apk info gtk+3.0-9999_git20210602-r2
$ sudo apk policy gtk+3.0-9999_git20210602-r2
$ sudo a...On two packages (gtk4.0-9999-r2, gtk+3.0-9999_git20210602-r2) on postmarketOS, `apk info` and `apk policy` will just display nothing:
```
$ sudo apk info gtk+3.0-9999_git20210602-r2
$ sudo apk policy gtk+3.0-9999_git20210602-r2
$ sudo apk policy gtk4.0-9999-r2
$ sudo apk info gtk4.0-9999-r2
$
```
I'm not sure what exactly it's meant to output, but probably something other than nothing. This is the affected apk version:
```
$ apk --version
apk-tools 2.12.9, compiled for aarch64.
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10862Fetch fails to detect broken IPv62022-12-21T19:39:44ZReuben LifshayFetch fails to detect broken IPv6If apk is running in a dual stack environment where AAAA records are returned but IPv6 packets do not go through fetch will try to connect only to the v6 addresses and will take a very long time to fail and fall back to v4. In my case, t...If apk is running in a dual stack environment where AAAA records are returned but IPv6 packets do not go through fetch will try to connect only to the v6 addresses and will take a very long time to fail and fall back to v4. In my case, this is with building docker images.
Other utilities such as `curl` work correctly in the same situation because they use the Happy Eyeballs algorithm ([RFC 8305](https://www.rfc-editor.org/rfc/rfc8305)).
apk:
```
~ # apk update
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
...(hangs until timeout)
```
curl:
```
~ # curl -vI https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
* Trying 2a04:4e42:600::645:443...
* Trying 151.101.194.133:443...
* Connected to dl-cdn.alpinelinux.org (151.101.194.133) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...CLIPPED
```
curl IPv6 only:
```
~ # curl -6 -vI https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
* Trying 2a04:4e42::645:443...
...(hangs until timeout)
```backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10861implement support for OCI registries2022-12-21T18:56:11ZAriadne Conillariadne@ariadne.spaceimplement support for OCI registriesWith projects such as ORAS (OCI Registry as Storage), it may be interesting to support fetching apk packages as if they were objects stored in OCI registries. This would allow users to distribute apk packages at zero cost by using pre-e...With projects such as ORAS (OCI Registry as Storage), it may be interesting to support fetching apk packages as if they were objects stored in OCI registries. This would allow users to distribute apk packages at zero cost by using pre-existing OCI registries such as DockerHub, GHCR, etc.
Other package managers, such as Homebrew, have implemented support for this distribution method. I believe OpenWrt developers have expressed interest in this as well.
(This would be for something after apk 3.0 release.)v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10860Implement an option for never running apk interactively regardless of whether...2022-12-20T13:41:18ZNewbyteImplement an option for never running apk interactively regardless of whether /etc/apk/interactive existsIn postmarketOS, we have decided to do the inverse of what Alpine does with regards to interactiveness of apk and ship `/etc/apk/interactive` by default and let users delete it if they don't want it. We do this using a post-install trigg...In postmarketOS, we have decided to do the inverse of what Alpine does with regards to interactiveness of apk and ship `/etc/apk/interactive` by default and let users delete it if they don't want it. We do this using a post-install trigger for our base OS package. This is great for us as it makes postmarketOS more familiar to users coming from distributions that don't use apk (which probably applies to most of our users), and also since it allows users to manually audit transactions for unexpected changes before they run them.
However, this has caused problems for our tooling as in some situations this means apk will prompt the user to confirm transactions when they're run in a context where apk is meant to be run non-interactively. One possible solution to this would be to temporarily remove and re-add `/etc/apk/interactive` as necessary, but I think this sounds hacky and error-prone. As such, I would like to see some way of forcing apk to ignore checking for `/etc/apk/interactive` and always run non-interactively. Does this sound like a reasonable proposal?
Related: https://gitlab.com/postmarketOS/pmaports/-/issues/1770https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10859apk3: handle xattrs2023-10-15T16:38:22ZDaniel Kolesaapk3: handle xattrsIt seems adb does not handle those at all yet (even though the other layers support them).It seems adb does not handle those at all yet (even though the other layers support them).v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10858`apk add ...` should attempt to redownload an apk package with a bad signatur...2022-12-21T18:56:11ZEllie`apk add ...` should attempt to redownload an apk package with a bad signature at least once during the command run`apk add ...` should attempt to redownload an apk package with a bad signature at least once during the command run. Instead it just gets stuck dumbfounded and always gives the same failed output even if the command is rerun:
```
$ sudo...`apk add ...` should attempt to redownload an apk package with a bad signature at least once during the command run. Instead it just gets stuck dumbfounded and always gives the same failed output even if the command is rerun:
```
$ sudo apk add py3-pip
(1/12) Installing py3-contextlib2 (21.6.0-r2)
(2/12) Installing py3-tomli (2.0.1-r1)
(3/12) Installing py3-pep517 (0.12.0-r2)
(4/12) Installing py3-six (1.16.0-r1)
(5/12) Installing py3-retrying (1.3.3-r3)
2% ██
(6/12) Installing py3-appdirs (1.4.4-r3)
2% ██
3% ██
(7/12) Installing py3-more-itertools (8.13.0-r0)
3% ██
4% ███
5% ███
(8/12) Installing py3-ordered-set (4.0.2-r3)
5% ████
(9/12) Installing py3-parsing (2.4.7-r3)
5% ████
ERROR: py3-parsing-2.4.7-r3: IO ERROR
(10/12) Installing py3-packaging (21.3-r0)
8% ██████
ERROR: py3-packaging-21.3-r0: BAD signature
(11/12) Installing py3-setuptools (59.4.0-r0)
10% ███████
ERROR: py3-setuptools-59.4.0-r0: BAD signature
(12/12) Installing py3-pip (22.1.1-r0)
23% █████████████████
ERROR: py3-pip-22.1.1-r0: BAD signature
100% █████████████████████████████████████4 errors; 2154 MiB in 814 packages
$
```
For such an obvious culprit, I would expect it to do *something* when it runs into broken packages like that. at the very least when I try running the command again.
I saw this with apk 2.12.9 on postmarketOS 22.06.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10857`apk cache clean` doesn't remove package downloads in /var/cache/apk/2023-10-12T10:08:43ZEllie`apk cache clean` doesn't remove package downloads in /var/cache/apk/`apk cache clean` doesn't remove package downloads in /var/cache/apk/ with apk 2.12.9 as found on postmarketOS 22.06. I think it would be highly expected that it does, so I suggest that it is changed to do so. This is especially irritati...`apk cache clean` doesn't remove package downloads in /var/cache/apk/ with apk 2.12.9 as found on postmarketOS 22.06. I think it would be highly expected that it does, so I suggest that it is changed to do so. This is especially irritating with apk getting stuck on a corrupted download, somehow not being smart enough to do anything about it even on retrying install, and then `apk cache clean` just does nothing of use. Very confusing!v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10856apk3: failure upgrading packages if newer version replaces file with directory2022-12-21T18:56:12ZDaniel Kolesaapk3: failure upgrading packages if newer version replaces file with directoryOne will get a `not a directory` error when trying to upgrade a package and the newer version has a directory where the previous version had a file.One will get a `not a directory` error when trying to upgrade a package and the newer version has a directory where the previous version had a file.v3.1