Document real world use

[davidak]

How would someone actually use this?

Who is this for? Only for people with higher security requirements that don't trust hydra builds, or should it be enabled on every Nix install at some point?

How would it be configured on a mobile device (notebook, no static network, behind firewall), workstation (pc, static ip, behind firewall) or server (VPS, static ip, public ip)?

What if i use all 3 kinds of devices? Should i collect logs only on one? Or should i have different names and key-pairs for all of them?

What to do if one builder get compromised? Do i have to revoke my vote that i have build the software, or does the system naturally handle the case that one hash is different than the others? (i think yes)

What is a sane policy for a nixos user (and contributor)? As i understand e.g. 2/3 majority requires at least 3 different builds, so i have to subscribe to 3 logs (how do remotes relate to that?) that have build the package i want.

To what log should i subscribe? Do i have to trust it? (that would defeat the whole purpose and i could just add their binaryCaches)
Or can i just subscribe to random logs? What if N$4 actually advertises millions of logs, i subscribe to them and they succeed in a 51% attack?

A use case might be unfree packages that are always build locally, like Steam. So i would subscribe to the logs of other steam users and when 3 people have build it before, i can just download it from them. But providing such packages for download might be a copyright violation. So maybe not share such packages? Maybe we as foss community could get a reference court decision that when it's clear that i get the same file if i build it myself or download, it's legally fine to download it and it's considered as if i built it myself.

Could someone guess my passwort in a config file and pull that file from me to verify it? Should we add and share configurations at all? (the problem is Nix internally don't know what a package, test or configuration is)

I'm often building packages changed in a nixpkgs PR to review it. The submitter has build it too as well as ofborg. How can we verify that we have the same hash (to see the package is build reproducible)? How can we do that on a big scale for all nixpkgs contributors?

How can we check all published logs if a package have different hashes and is therefore not reproducible? I guess trustix-nix-reprod is intended for that. But there is no documentation yet.

What happens when a package is not reproducible? The hashes will never match and it will not be a majority, so it will be always build locally.

Can i configure this to get packages that where build by hydra from a closer cache that i don't have to trust? So i ask hydra for the hash and ask random close stores (local network at company or university, random from nearby ip range measured by geoip and ping)?

How to configure it to always fall back to hydra?

How would a use case look like where i don't trust hydra builds?

Imagine this is enabled on NixOS by default. What are the default subscribers? Can i as a regular user add my own logs to that list?

Do remotes need to be a public domain that resolves to a public IP? How can that work for notebooks behind nat + firewall?

When i destroy a system (like temporary container/vm), can i transfer the logs to another system to preserve them?

What else is possible when this would have 5000 users?

not everyone has the same level of trust in different build servers, or the same security requirements. By defining consensus and having the vote client-side, we end up with a model that is much more flexible and can be tuned to your use cases and threat model.

can we have multiple sane defaults for security levels, like

i trust no one = always build locally
i only trust myself = use other logs owned by myself
i trust the community = list of community logs maintained in nixpkgs. optionally only verified nixpkgs contributors or committers
i trust nixos foundation = use cache.nixos.org as truth, but also use other caches like from community when hashes match
i trust everyone = use all logs available (are they discovered peer-to-peer?)

If the default voting mechanism is majority-rules, then an attacker would need to gain control of 51% of all configured nix Trustix logs, including access to the log’s private key, an attack which is extremely unlikely. Keep in mind that even if this should happen, high-profile targets would likely have configured their own voting procedure, so they would be unaffected.

how does a voting procedure look like that is unaffected from 51% attack? 2/3 majority? 9/10 majority?
how much do i have to trust the logs i subscribe? would you add my log if you where a high-profile target? i might be kind of trustworthy since i'm around for 5 years, but they could pay me good and i will add their malware... but they would have to do that with many community members and it's unlikely that no one talks about it. so just subscribe to a diverse set of logs from different community members?

Can you add a community registry where people can add their logs, so we can test with as many logs as possible?
It should have some metadata like maintainer (from nixpkgs. used as name, e-mail, ...).
Have a nixos option to enable them.

[kpcyrd]

In case this is useful, we currently collect public rebuilderd instances on https://rebuilderd.com/, most of them are rebuilding Arch Linux packages. There are 3 tools to query the status:

• https://github.com/kpcyrd/ismyarchverifiedyet
• https://github.com/archlinux/arch-repro-status
• https://github.com/kpcyrd/pacman-bintrans

The last one of those explicitly hooks into pacman and allows configuring rules like "at least two rebuilders need to confirm this build". This doesn't work well in practice yet because some essential packages are not reproducible though.

You would only configure to query rebuilders you trust to operate honestly and configure a threshold that's higher then than the number of rebuilders you suspect to possibly collude.

[davidak]

You would only configure to query rebuilders you trust to operate honestly

If we trust them 100% we wouldn't need all this effort. But i agree one might not want to discover random rebuilders and use them, rather from known community members.

configure a threshold that's higher then than the number of rebuilders you suspect to possibly collude.

So a 2/3 majority seem to be a good default. One rebuilder could have technical issues or be malicious, but if 2 other agree, it should be safe. It get's more safe the more rebuilders are there.