Reprodukovatelný build

Reprodukovatelný build dává bit po bitu shodný výstup pokaždé, když kdokoli sestaví stejný zdrojový kód ve stejném prostředí buildu a podle stejných instrukcí pro build. Tak to definuje projekt Reproducible Builds. Výstupem se zde rozumí artefakty, kvůli kterým build probíhá: spustitelné soubory, distribuční balíčky, image kontejnerů nebo souborových systémů. Logy se nepočítají. „Znovu se to sestaví“ není totéž; reprodukovatelný znamená, že se shodují bajty.

Proč většina buildů reprodukovatelná není

• Řešení závislostí během buildu. Bez lockfilu vybírá správce balíčků verze až při běhu buildu. Řešení závislostí z PyPI může skončit různě podle pořadí, v jakém dorazí odpovědi, rozsah verzí se posune, když vyjde nové vydání, a měnitelný tag jako latest začne ukazovat jinam.
• Prostředí. Časová razítka, cesty k souborům, locale a vlastní nástroje hostitele skončí uvnitř artefaktů.
• Náhodnost. Kroky buildu mohou generovat ID, řadit soubory podle hashe nebo pokaždé spouštět paralelní práci v jiném pořadí.

Dva buildy stejného commitu po sobě tedy nezaručují stejný výsledek ani stejnou SBOM. Build, který stahuje kód, jenž jeho lockfile neuvádí, tedy skrytou závislost, situaci ještě zhoršuje.

Jak týmy dosahují reprodukovatelných buildů

• Připněte a uzamkněte každý vstup, včetně základních image podle digestu a nástrojů podle verze (viz lockfile).
• Místo hodin použijte pevný čas: SOURCE_DATE_EPOCH je standardní proměnná prostředí s unixovým časovým razítkem, které nástroje pro build používají místo aktuálního času.
• Odstraňte nebo normalizujte cesty buildu, seřaďte seznamy souborů a zafixujte locale.
• Sestavujte v hermetickém prostředí, jehož toolchain je sám připnutý. Jednou z cest je Nix.
• Ověřte to: sestavte stejný commit dvakrát, nezávisle (na jiném stroji, v jiné cestě, jiný den) a porovnejte výstupy. Kde se hashe liší, diffoscope přesně ukáže, co se změnilo.

Projekt Yocto ukazuje, proč je reprodukovatelnost vlastnost, kterou je třeba ověřit, a ne předpokládat. Jeho dokumentace uvádí, že buildy projektu jsou od vydání 3.1 reprodukovatelné „down to the binary level including timestamps“ (až na úroveň binárek včetně časových razítek), že úplnou reprodukovatelnost zaručují jen BitBake a OpenEmbedded-Core a že „the moment you add another layer, this warranty is voided“ (jakmile přidáte další vrstvu, tato záruka zaniká). Projekt to testuje pomocí oe-selftest.

Reprodukovatelné buildy a SBOM

Kdyby byl každý build reprodukovatelný, mohli byste staré vydání později znovu sestavit a vygenerovat jeho SBOM. Většina reprodukovatelná není, takže nový build nebo dnešní sken zdrojového kódu popisuje podobný build, ne ten, který jste dodali. SBOM, která ukazuje, co běží v produkci, je ta zaznamenaná z buildu CI, který vydání vytvořil.

Ani reprodukovatelný build potřebu takového záznamu neodstraňuje. Shodné hashe dokazují, že dva buildy vytvořily stejný výstup; neuvádějí, co do něj vstoupilo. Inventář stále potřebujete, a k němu poctivé vyjádření jeho úplnosti SBOM. Podrobnější argumentaci najdete v článcích Proč je CI tím pravým místem pro bezpečnost dodavatelského řetězce a Osvědčené postupy pro SBOM.

SLSA považuje reprodukovatelnost za jeden ze způsobů, jak ověřit, že build udělal to, co tvrdí.

Reprodukovatelnosti týmy dosahují ve svém build systému, pomocí nástrojů jako Nix, Yocto nebo nástroje Debianu. CRACI buildy reprodukovatelnými nedělá: zaznamenává SBOM každého buildu během jeho běhu, takže záznam o tom, co bylo dodáno, nezávisí na opětovném sestavení. Viz SBOM z doby buildu.