Skip to content

Commit fbb3321

Browse files
committed
up
1 parent bcf5e69 commit fbb3321

File tree

1 file changed

+28
-0
lines changed

1 file changed

+28
-0
lines changed

kinds-of-reproducible-builds.md

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
---
2+
title: The Different Types of Reproducible Builds
3+
---
4+
5+
# The Different Types of Reproducible Builds
6+
7+
Reproducible builds are a set of software development practices to support an independently-verifiable path from source to binary code.
8+
Why its matter:
9+
10+
- **Security**: It allows verification that no vulnerabilities or backdoors were introduced during compilation
11+
- **Trust**: It enables multiple parties to validate that binaries match the published source code
12+
- **Quality Assurance**: It provides consistency in testing and deployment environments
13+
- **Long-term Maintenance**: It makes it possible to recreate development environments years later
14+
15+
## Kinds of reproducible builds
16+
17+
**Same-environment reproducibility**: Ensures that building the same source code with the same build environment produces identical binary outputs, byte-for-byte.
18+
19+
**Different-environment reproducibility**: Ensures that building the same source code within different build environment produces identical binary outputs, byte-for-byte. A classical example is changing the opearting sytem.
20+
21+
**Package-registry reproducibility**: Ensures that it is possible to rebuild an artefact published on a package registry (say NPM or Maven Central) given only the package registry data as input.
22+
23+
**Time-travel reproducibility**: Ensures that building the source code of the past (possibly years before) is still possible, producing identical binary outputs. The challenge is that dependencies evolve over time, and disappear.
24+
25+
**Functional reproducibility**: Focuses on ensuring that builds produce binaries with identical functionality, even if there are minor, non-functional differences in
26+
the output files (like timestamps or build paths). Typically, verifiers apply some kind normalization / canonicalization on the build output to achieve this.
27+
28+

0 commit comments

Comments
 (0)