paris2018: fix some spelling mistakes

-   Debian is 94% reproducible in theory and 0% in practice. How to fix

    that?

-   Conflict resolution/trust. How tdo we help people make good

-   Conflict resolution/trust. How do we help people make good

    decisions when independent builds do not reproduce?

-   How can we make it possible to know who and how many people have

Doc

-   Imrprove documentation for r-b testing dashboard

-   Improve documentation for r-b testing dashboard

-   Find, refine, document core concepts: rebuilders, buildinfo

-   (Think about) trust management for rebuilders

-   Reproducing packages in the Debian arcive

-   Reproducing packages in the Debian archive

-   How to ensure rebuilder operator diversity and create trust in their

    claims

- Define different trust models and architectures?

- standardised way of verifying reproduciblity

- standardised way of verifying reproducibility

- Identify user stories

Questions that arised from looking at these terms:

* How much environemnt must you capture for a reproducible

* How much environment must you capture for a reproducible

NPM/Maven/Python (which are multiplatforms so the issues might be

different than with distributions)?

* If an environment variable is not in a .buildinfo, can it be set to

anything or must it be unset?

* How much can I vary the build environment and exepect to get the same

* How much can I vary the build environment and expect to get the same

results?

* Must cross-copmilers yield the same results than same architecture

* Environment has two conflicting definitions: everything (which might

include phase of the moon, order of directory entries) vs. (known-to-be)

revelant (things we can and wil be set as inputs)

relevant (things we can and wil be set as inputs)

* \"degrees of freedom\" (are they enummerable?)

* \"degrees of freedom\" (are they enumerable?)

* \"the \_complement\_ of things you do specificy... is what \_must

not\_ afect outputs.\"

not\_ affect outputs.\"

* What do we call a system composed of the actions of two package

managers?

* diverse compiler binaries? (from the same source, but build

differently)

* diverse compier (e.g. gcc vs clang)

* diverse compiler (e.g. gcc vs clang)

* Is an execution profile part of the source code? (for Profile Guided

Optimization)

* Does build results contain relationships to other packages?

* WHat is the total set of dependencies being cosidered as candidates

* What is the total set of dependencies being considered as candidates

during resolution?

* ... and can we snapshot it? (and address those snapshots?)

Rust long boostrap chain

Rust port tonew architecture

Rust port to a new architecture

Replay history vs create new route

Not all projects have buildinfo files

are .buildinfo files without inary checksums useless? (Archlinux has

Are .buildinfo files without binary checksums useless? (Archlinux has

those)

is it enough / useful if rebuilders publish a stripped down version of

Is it enough / useful if rebuilders publish a stripped down version of

.buildinfo files?

Current Debian .buildinfo files are unreproducible

*\* Company employees installing internal software

- For internal company software, being able to check the source/binary

correspondance helps debugging ("reproducibility of bugs") and

correspondence helps debugging ("reproducibility of bugs") and

ensures you're running the right software.

- Reproducible builds can help make license auditing because you can

scheduler

- schould have authority over the build queue - builders (the thing

- should have authority over the build queue - builders (the thing

inside chroot) should not have direct access to it

builders (use fresh chroot)

- malicious/compromised packager → with reproducible builds we care

about malicious binary package

- random person submiting buildinfo file

- random person submitting buildinfo file

out of scope:

*\* empty classes build

*\* inhertance all done

*\* inheritance all done

*\* ignore type checking \-- as far as we can

- big cluster systems might have new big problems

- wrong calculations, hardhare have bugs. r-b can find serious bugs

- wrong calculations, hardware have bugs. r-b can find serious bugs

[mfl\] I think incorrect results, or in other words undetected user

level data corruption are extremely low probability. All CPU vendors are

random bit-flips, but are protected through SECDED (Single Bit Error

Correction Double Bit Error Detection). In addition the majority of

external memories has a chip-kill feature, i.e. the ECC bits are laid

out in way accross the multiple memory chips that an entire chip can

out in way across the multiple memory chips that an entire chip can

fail.

RAS (Reliability Availability and Serviceability) have become common in

But programs or build process require such behaviour

[mfl\] The point here is that certain HW elemenents can have a

life-cycle of decades. We need to pro-actively reserach potential

life-cycle of decades. We need to pro-actively research potential

pitfalls

- fpga: are not reproducible because of place and route, which usually

placed&routed succesful. Any error there should probably be seen similar

to a compiler error generating wrong code.

Need to evaluate if it is feasable to create hashes for bitstreams.

Need to evaluate if it is feasible to create hashes for bitstreams.

- r-b become reproducible calculations. because some hardware does not

guarantee reproducible calculations.

- everybody loves bitflips

mfl again I don\'t see bitflips as soemthing which will show up at the

user level. If there is other proof on this we obviosly need to

mfl again I don\'t see bitflips as something which will show up at the

user level. If there is other proof on this we obviously need to

re-consider

- it probably would be helpful to include low level HW details into

- box could be package manager, could be around each rebuilder

- who defines the treshold

- who defines the threshold

verification:

- certificate transparency log

if one of the signing keys gets compromised, with a CT you can see

whether some pakcage was signed out of the official loop

whether some package was signed out of the official loop

for the n+1 threshold (n should be chosen by the user), the negative

matters as well

- apt install a requires b

- concern: treshold for 1.1 is not there, but 1.0 is there

- concern: threshold for 1.1 is not there, but 1.0 is there

- first resolve all the packages, then install something

* Check for special cases when they are found

* Add a script for Arch JSON output, similiary to debian json output

* Add a script for Arch JSON output, similarly to debian json output

(bin/reproducible\_json.py)

* Guix json output from guix-challenge to be coded to allow importing

local reproducibility (storing hashes on the first run and check on the

second round)

check reproducibility w.r.t. hashes provided by independet rebuilders

check reproducibility w.r.t. hashes provided by independent rebuilders

opam should have a way to clearly specify the external dependencies in

order to be able to exactly record and reproduce the

build environement, including versions.

build environment, including versions.

- GCC

From the first input, using cp / mirage-configure & opam (todo),

generates all informations for the rebuild input. Once we get these,

using \"simple\" commands, it is possible to generate the rebuild and

then compare unikernal binary & hypervisor config

then compare unikernel binary & hypervisor config

Specification of

binary. Since some 

* Investigate if PGO is hardware dependend? Or is the issue how longer

you run a Proifle how much different optimisations you get?

you run a Profile how much different optimisations you get?

A simple PGO example with a fixed input is reproducible on at least two

different sets of hardware. The question is, if a more complicated

program with different input is reproducible.

Worked on identifing if grep can be PGO\'d and reproducible such as

Worked on identifying if grep can be PGO\'d and reproducible such as

openSUSE has achieved. The grep build isn\'t always reproducible but

sometimes is. This might depend on how long it takes to run the test

suite which is fed to the

Opaque object (binary, ml model, bytes)

Noun is reminescent of \"archeology\"!

Noun is reminiscent of \"archeology\"!

Generated Source?

Indicates dependencies (runtime/buildtime/install)?

Organization unit with semntics

Organization unit with semantics

Docker images: they\'re files, but also have a mainfest.json which

contains semantics. So is this a package? An application?