• Linux or WSL2 Ubuntu (developed on WSL2 on Windows 10).
• Docker — used as Melange's build-sandbox runner and to load/run the final image.
• melange and apko on PATH.

Versions used during development:

All commands below are run from the repository root.

Build & test — exact commands

1. Generate a signing key (one-time)

Produces melange.rsa (private) and melange.rsa.pub (public). Both are gitignored — keys are regenerated by whoever reproduces the build, never committed.

2. Build the package

--source-dir patches makes patches/cve-2026-33320.patch available inside the build sandbox, where the recipe's patch step applies it. Output: packages/x86_64/dasel-3.3.1-r0.apk (signed) and packages/x86_64/APKINDEX.tar.gz.

3. Test the package

melange test installs the freshly built .apk into a clean environment and runs the recipe's test: block. It needs the Wolfi repo (for busybox) and our local packages/ repo (for dasel), each with its signing key:

Asserts: dasel version reports 3.3.1; a real JSON query; a JSON→YAML conversion; and that a billion-laughs YAML bomb is rejected by the expansion guard (CVE-2026-33320 fixed).

4. Build the image

Output: dasel.tar (a loadable OCI image) plus an SBOM (SPDX JSON). apko appends the architecture to the tag, so the loaded image is dasel:test-amd64.

How the image consumes the locally built package (the key constraint). apko/dasel.yaml lists ./packages as a repository and ./melange.rsa.pub as a keyring. So apko installs the exact dasel APK that melange build wrote into packages/x86_64/ — verified against our own signing key — and not a prebuilt upstream package. (Run apko build from the repo root so those relative paths resolve.) This is what connects the package build to the image build.

5. Run the image test

Runs the image via docker run and asserts (5 checks): dasel is present and reports v3.3.1, a nested JSON query, a JSON→YAML conversion, an array-index query, and the YAML bomb rejected. The script exits non-zero if any check fails (so it can gate CI). Override the tag with IMAGE=<tag> ./tests/test.sh.

The CVE-2026-33320 fix

CVE-2026-33320 is a denial-of-service (CWE-674, uncontrolled recursion) in dasel's YAML reader: a "billion laughs" attack via unbounded YAML alias expansion. dasel implemented its own UnmarshalYAML and resolved alias nodes recursively with no limit, bypassing the underlying library's built-in protection.

We backport only the upstream fix (commit 282943b, shipped in v3.3.2) onto the v3.3.1 source as patches/cve-2026-33320.patch. It bounds expansion with a depth limit (32) and a shared budget (1000), returning an error instead of expanding without bound. We deliberately exclude the unrelated bug fixes that also shipped in v3.3.2, keeping the change minimal and auditable. See patches/NOTES.md for full details.

Design decisions

• Pinned source. git-checkout pins expected-commit to the v3.3.1 commit SHA, so the build fails if the tag is ever re-pointed at different code (supply-chain safety).
• Minimal patch. Only the CVE fix is applied — nothing else — for auditability.
• Static binary. Built with CGO_ENABLED=0 (set in the recipe's build environment), so the binary has no cgo and no shared-library dependencies — which is what lets the image ship with no libc/shell/package-manager.
• Minimal image. The apko packages: list is just dasel; the image installs only our locally built package (verified with our melange.rsa.pub).
• Non-root. The image runs as uid 65532 (nonroot) for defense-in-depth.
• Signed. Both the package and the package index are signed; apko verifies signatures.

Assumptions

• Building for x86_64 only (the development machine's architecture).
• Using docker as Melange's runner (bubblewrap would also work on native Linux).
• The image carries no base-layout package (hence no /etc/os-release); nothing in the image needs it. This is a deliberate minimality choice, trivially reversible by adding wolfi-baselayout.
• The build pulls Wolfi's rolling go and busybox rather than pinned snapshots, so it assumes Wolfi keeps serving a Go ≥ 1.25 (dasel's go.mod requirement). The dasel source is pinned by commit; pinning the build toolchain too would make the build fully hermetic (see below).

What I'd improve with more time

• Port upstream's exact boundary unit tests (depth 32 vs 33, budget 1000 vs 1001, multi-document budget reset) for finer coverage than our black-box budget/depth bomb tests.
• Pin the build toolchain (specific Wolfi go/busybox snapshots) and a fixed build date for a fully hermetic, bit-for-bit reproducible build (the source is already commit-pinned).
• Multi-arch build (aarch64) for ARM machines.
• Image signing with cosign, and verifying the melange/apko release binaries' signatures.
• A CI workflow (GitHub Actions) to rebuild and run both test suites on every push.

Submission notes

• All commands above were run and pass on WSL2 Ubuntu with Docker Desktop.
• melange build + melange test: package builds, patch applies cleanly (all 7 hunks — 1 in parsing/yaml/yaml.go, 6 in parsing/yaml/yaml_reader.go), all package tests green including the CVE bomb test.
• apko build + tests/test.sh: image builds (~4 MB content), all 5 image tests green.
• The "What I'd improve" section above lists the next steps I'd take with more time.