swm_version: 1 base: distro_version: dev pins: {} mutations: - type: source_patch tarball: https://gitlab.alpinelinux.org/alpine/ca-certificates/-/archive/20260611/ca-certificates-20260611.tar.bz2 sha256: 32ca73f2e81e2b88dc614f12e1ee04a82b1ec5a8e29d9f359ddf8905a0afcbb0 build: compiler: zig-cc target: x86_64-linux-musl link: static flags: [] phases: compile: | _abuild_phase() { make } _abuild_phase install: "_abuild_phase() {\nmake install DESTDIR=\"/out\"\n\n\t(\n\t\techo \"# Automatically generated by ca-certificates-20260611-r$pkgrel\"\n\t\techo \"# $(date -ud@$SOURCE_DATE_EPOCH)\"\n\t\techo \"#\"\n\t\tcd \"/out\"/usr/share/ca-certificates\n\t\tfind . -name '*.crt' | sort | cut -b3-\n\t) > \"/out\"/etc/ca-certificates.conf\n\n\t# generate the bundle in similar way as update-ca-certificates would do\n\tfind -- *.crt | sort | while read -r i; do\n\t\tcat \"$i\"\n\t\tprintf \"\\n\"\n\tdone > \"/out\"/etc/ssl/certs/ca-certificates.crt\n\n\tmkdir -p \"/out\"/etc/apk/protected_paths.d\n\tcat > \"/out\"/etc/apk/protected_paths.d/ca-certificates.list <<-EOF\n\t\t-etc/ssl/certs/ca-certificates.crt\n\t\t-etc/ssl/certs/ca-cert-*.pem\n\t\t-etc/ssl/certs/[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f].[r0-9]*\n\tEOF\n\n\tcat > \"/out\"/etc/ca-certificates/update.d/certhash <<-EOF\n\t\t#!/bin/sh\n\t\texec /usr/bin/c_rehash /etc/ssl/certs\n\tEOF\n\tchmod +x \"/out\"/etc/ca-certificates/update.d/certhash\n\n\t# ── LOS HASH-LINKS, HECHOS EN EL BUILD (2026-09-14) ──────────────────────────────────────\n\t# En Alpine ese hook de arriba lo ejecuta `apk` al instalar. **Acá no lo ejecuta nadie**: takana\n\t# proyecta artefactos, no corre post-install. Resultado medido en la caja de producción: el\n\t# `curl` de la distro está compilado con `--with-ca-path=/etc/ssl/certs` y SIN CAfile, así que\n\t# mira un directorio que sólo tiene el bundle — y **no puede validar ningún certificado**:\n\t#\n\t# * CApath: /etc/ssl/certs\n\t# * SSL certificate ... unable to get local issuer certificate (20)\n\t#\n\t# No falla al construir ni al instalar: falla la primera vez que la caja intenta bajar algo por\n\t# HTTPS (`qorpa pull`, `install --repo https://…`, el mirror). Con `--cacert` el mismo curl da\n\t# 200, que es la prueba de que los certificados están y lo que falta es el ÍNDICE.\n\t#\n\t# Se generan acá, donde `c_rehash` y perl existen, y viajan dentro del artefacto.\n\t# ⚠ `c_rehash` lo compila e instala ESTA receta (`install -m755 c_rehash /out/usr/bin`), así que\n\t# no está en el `PATH` del sandbox: hay que invocarlo por su ruta de destino. La primera versión\n\t# lo llamaba por nombre, no lo encontraba, y la guarda de abajo cazó el silencio.\n\t# ⚠ Los certificados NO están sueltos en `usr/share/ca-certificates/`: cuelgan de un\n\t# subdirectorio (`mozilla/`). El primer intento copiaba `…/ca-certificates/*.crt`, no casaba con\n\t# nada, y `c_rehash` sólo encontraba el bundle — que salta con «does not contain exactly one\n\t# certificate», que es correcto y parecía el problema cuando el problema era que no había nada\n\t# más que mirar.\n\tfind \"/out\"/usr/share/ca-certificates -name '*.crt' -exec cp {} \"/out\"/etc/ssl/certs/ \\;\n\t\"/out\"/usr/bin/c_rehash \"/out\"/etc/ssl/certs || ./c_rehash \"/out\"/etc/ssl/certs || true\n\t# Falla ruidosamente si el rehash no produjo NADA: un capath sin enlaces es exactamente el bug\n\t# que esto viene a cerrar, y sellarlo en silencio lo devolvería intacto.\n\tn=$(find \"/out\"/etc/ssl/certs -name '*.0' | wc -l)\n\t[ \"$n\" -gt 0 ] || { echo \"ca-certificates: c_rehash no generó hash-links en /etc/ssl/certs\" >&2; exit 1; }\n\techo \"ca-certificates: $n hash-links en el capath\"\n}\n_abuild_phase\n" strip_debug: true target_bin: /usr/bin/ca-certificates expected_hash: b3:771c6251ae0a72bb46f7d8f89a2b9d1fd1469c1b9af85b4f6c8ef3e29a1a4892 deps: build: - binutils - openssl - perl runtime: []