apk-v2(5)

💅 apk-v2(5) — like, the whole entire vibe of the apk v2 format, bestie

okay so this is the apk-v2(5) page from the File Formats Manual, and I'm gonna walk you through it because honestly? it's giving "elegant tarball" and I'm obsessed ✨

🌸 NAME 🌸

apk v2 — the whole overview of the apk v2 format. that's it, that's the vibe check 💖

🦋 DESCRIPTION 🦋

so a v2 .apk file contains, in this order of importance: a single package's contents, some metadata, and some signatures. literally all three, bestie 🫶

the .apk file itself contains three concatenated gzip streams, which together form a single tar archive. and that tar archive contains three sections:

1. the signatures
2. the control section
3. the data section

no cap, that's the whole structure. slay.

---

🔥 THE SIGNATURES 🔥

the signatures are a sequence of files whose names start with .SIGN., and they must come before any other data in the tarball. like, main character energy — they go first, periodt.

these filenames look like:

.SIGN.<algorithm>.<keyid>

where <algorithm> must be one of DSA, RSA, RSA256, and RSA512 — and <keyid> must be the name of the key's file in /etc/apk/keys (peep apk-keys(5) for that one 👀).

now, the signature can be computed over either the metadata (if the metadata contains a data hash for the data), or over the metadata and data together (if the metadata contains no data hash). it's giving "two paths, same destination" honestly 💫

and here's the cute part: a single signature from a trusted key is sufficient, so an apk can be signed by multiple different keys if need be, as long as clients trust at least one of them. teamwork makes the dream work fr fr 🌈

---

🎀 THE CONTROL SECTION 🎀

in a v2 apk file, the package metadata is stored in a single file called PKGINFO. That file uses a key-value format, in which keys and values are separated by " = " and lines beginning with # are comments. iconic.

there are many allowed keys and there is no centralized list of known keys — the source of abuild(1) is the best reference. iykyk 😌

one key is important for understanding the v2 format because it affects the interpretation of the signature: if there is a "datahash" key in PKGINFO, its value is the sha256 hash of the data part of the apk. packages are supposed to have a datahash, but indexes do not. noted 📝

the control section is also where pre/post hook scripts for install, deinstall, and upgrade live, and where triggers live. it's a whole little neighborhood in there 🏡

---

🧚 THE DATA SECTION 🧚

the data section is simply a tar archive of the package's contents, as produced by the build process. easy enough 💅

these files are postprocessed by abuild-tar(1) and use pax extended headers to include per-file checksums in a header named APK-TOOLS.checksum.<hash>. fancy, but make it functional ✨

---

⭐ EXAMPLE ⭐

as an example, the v2 apk for scdoc(1) itself contains these files in this order:

.SIGN.RSA.alpine-devel@lists.alpinelinux.org-6165ee59.rsa.pub
.PKGINFO
usr/
usr/bin/
usr/bin/scdoc
usr/share/
usr/share/pkgconfig/
usr/share/pkgconfig/scdoc.pc

since v2 apk files are simply tarballs (broken into multiple gzip streams), they can be inspected and unpacked with tar(1) — but ⚠️ care must be taken when changing them not to reorder the sections or invalidate the signature. it's better to use abuild(1) to modify them. trust 🙏

and if you want to take them apart into their constituent gzip streams, you can use abuild-gzsplit(1). literally so handy 💜

---

💀 NOTES 💀

only the "RSA" (meaning RSA + SHA1) signature scheme is currently used by abuild(1). that's the one in rotation, bestie 🎀

---

👑 SEE ALSO 👑

abuild(1), apk(8), apk-package(5), apk-v3(5)

---

and that's the page!! 🦋 this was apk-v2(5) from the File Formats Manual, dated 2026-11-02 — go read apk-v3(5) next if you wanna see the glow-up 💖✨💅