why make OpenWrt reproducible?

one (of many) metric for code quality

requires a level of code understanding

demonstrates that this understanding exists

security

compliance

for a community distro, benchmark to be proud of

upstream-first approach means we solve at the root

why wasn't it reproducible?

timestamps

vendor-/target-specific firmware image format quirks

kernel modules, esp. if used on few targets

(support hash-based module integrity checking!)

build env - categories

build env - examples

beyond the build env (Managing variance)

is OpenWrt reproducible?

many years of opkg history

>1 decade on reproducibility (slides) (video)

early work: Reproducible OpenWrt

at last!

but wait...

time to change everything

for the better!

apk (Alpine Package Keeper)

a very pleasant package format

from shell scripts to C

main apk-tools fixes: file ordering, SOURCE_DATE_EPOCH

beyond Alpine: using v3 indexes already

let's not forget the tool itself

other challenges

keen readers noticed inconsistent /init - now fixed

teaching diffoscope even more formats,
for human-readable output

defaults is a hexdump diff; nice but...

lots of vendor-specific partitioning :(

thanks to OpenWrt, now supported by diffoscope!

current status (images graph)

https://rebuilder-01.infra.openwrt.org/

current status (images examples)

https://rebuilder-01.infra.openwrt.org/

current status (packages graph)

https://rebuilder-01.infra.openwrt.org/

current status (packages examples)

https://rebuilder-01.infra.openwrt.org/

verifying the results

https://github.com/aparcar/openwrt-rebuilder

builds exactly what the buildbots build

more on why

https://reproducible-builds.org/

which problems do reproducible builds solve?