BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.devconf.info//devconf-cz-2026//talk//JM8CZM
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-devconf-cz-2026-JM8CZM@pretalx.devconf.info
DTSTART;TZID=CET:20260618T161500
DTEND;TZID=CET:20260618T165000
DESCRIPTION:Rebuild the same Containerfile with the same packages and you'l
 l get a different image hash. This isn't a bug—it's the default behavior
  of container builds\, and it breaks verification\, caching\, and supply c
 hain security.\n\nThis talk explores the surprisingly hard problem of repr
 oducible container builds. We'll dissect exactly what breaks reproducibili
 ty—timestamps\, SQLite journal modes\, machine-id files\, transaction lo
 gs—and show practical techniques to fix each one.\n\nWe'll cover:\n\n- L
 ive demo: same Containerfile\, different hash—why?\n- SOURCE_DATE_EPOCH 
 and timestamp normalization\n- The SQLite WAL surprise—and the one-line 
 fix\n- A checklist of artifacts to remove for reproducibility\n- Verificat
 ion: rebuilding from SLSA provenance attestations\n\nFrom Project Hummingb
 ird (70+ container images\, SLSA Level 3)\, we'll show how to achieve bit-
 for-bit identical rebuilds in your CI/CD pipelines.\n\n**Audience**: CI/CD
  engineers\, security teams\, anyone wondering why their image rebuilds do
 n't match.
DTSTAMP:20260430T125128Z
LOCATION:E112 (capacity 156)
SUMMARY:Why Your Container Builds Aren't Reproducible (And How to Fix It) -
  Michael Krausch-Hofmann
URL:https://pretalx.devconf.info/devconf-cz-2026/talk/JM8CZM/
END:VEVENT
END:VCALENDAR
