Pacman-bintrans, the reason I stick with Arch

pacman-bintrans, a binary transparency tool for pacman, provides some level of gossiping to stop split-world-attack. (with options like --required-rebuild-confirms and --bypass-proxy-for-pkgs). This is the reason I can’t leave Arch-Linux for Nix

Also I should mention it would be good if someone create a binary transparency tool based on (second layer of) a Proof-of-Work blockchain, because it doesn’t need gossiping to stop split-view-attack

pacman-bintrans, a binary transparency tool for pacman , provides some level of gossiping to stop split-world-attack.

I’m not sure what “gossiping” means, but it seems trustix is what you’re looking for.

it would be good if someone create a binary transparency tool based on (second layer of) a Proof-of-Work

There is this good blog post that argues that proof-of-* doesn’t actually make much sense for this use case. Essentially,

Notice that both proof-of-X solutions require big investment of capital. In the context of a cryptocurrency, where there is significant money to be made, those investments make sense. On the other hand, it’s not nearly as appealing for a company or an individual to operate a build log that comes with a similar cost every time a package build is submitted.

If two of Signal’s servers have different records, that could lead to problems if a user switches from one server to another. If two matrix servers disagree about the messages sent in a room, this can manifest as two groups of users unable to talk to each other. If everyone does not agree on the series of blocks in a blockchain, you have two blockchains, not one.

If two users disagree about which package to trust they… download different packages. This does not pose the same kind of existential threat or bad user experience as it does for the other systems.

1 Like

Firstly, thank you for tip. I didn’t know about Trustix.

What if a government buy both servers and ask them to send a different log to its citizens.
In proof of work model, clients just can require a level of difficulty for blockchain to find out if they are seeing an international powerful blockchain. (for high gas fees problem, a second layer can be used.)

It can achieved by putting a time limit on when the blockchain network solves blocks hash

What if a government buy both servers and ask them to send a different log to its citizens.

Do you mean if >50% of your trusted servers are compromised?
That can still happen in a PoW network. If you’re really worried about this you should disable binary caches and build from source.

Anyway, there are much better ways for a government to compromise a package that don’t require taking over a lot of servers. The easiest thing would be just knocking at the door of one the (hunders of) maintainers with commit access to Nixpkgs and force them to push their changes.


You are right

I actually mean eastern non democratic governments

Same thing applies. We’ve got committers from all over the world.

Would you be able to explain what this means? Maybe from the perspective of someone familiar with the NixOS ecosystem, but completely unfamiliar with the Arch Linux ecosystem?

Like, in practice what does pacman-bintrans do? I don’t really understand what a “binary transparency tool” is, or what is a “split-world-attack”, or how that would affect me in the NixOS ecosystem. Although I am interested to learn!


split-world-attack (a.k.a split-view-attack) is when a package’s publisher (server) gives some users a different (malicious) version of packages.

“Binary transparency” wants to mitigate such scenario. pacman-bintrans use an append-only log for checksum of packages and check hash of this log with a server (usually through a proxy to show different geo address). Also, it checks these checksums with independent builders’ servers (which build packages from source code). It uses the log transparency method (which needs checking checksums with multiple peers (servers) also known as “gossiping” to stop split-view-attack)


That’s extremely cool!

I’ve been quite nervous about NixOS’ centralized build infra to be honest. We have one centralised build farm and one centralised cache. I haven’t been able to find very convincing documentation that the security of this centralised infrastructure is sufficiently protected and it has always made me slightly uncomfortable.

One thing you can do if you’re absolutely paranoid and have a lot of compute power is disable substitution in Nix. Then Nix will build everything from source.

I hope innovations like trusix catch on. Also the work on Nix content addressed storage will likely contribute to this getting better over time


usually through a proxy to show a different geo-address from package downloading connection

That sounds really interesting.

Similar to What would you change in Nix or NixOS?, if you had a bunch of time and money to change the Nix ecosystem, what would you change to fix this split-world-attack?

For instance, would you have multiple hydra instances and binary caches? And then some sort of tool to compare the outputs between them? Would that be sufficient?

I’m wondering exactly what a solution would look like from an end-user in the Nix ecosystem.


50% attack is not relevant here as everyone will become aware of it when it happens