pacman-bintrans VS userscan

If you trust them with your keys, why not trust them with your plaintext? At which point, why bother with E2EE at all?

The answer should be "because one day web browsers will be able to pin specific versions of specific web apps, with specific hashes, corresponding to specific releases tagged in their repo, which have been audited by a certain threshold of auditors that I trust".

What that looks like in practice is probably some mixture of the following projects:

https://github.com/kpcyrd/pacman-bintrans

https://users.rust-lang.org/t/rust-code-reviews-web-site-for...

https://paragonie.com/blog/2022/01/solving-open-source-suppl...

Generally speaking, Transparency Logs for securing software distribution has been a research topic since around 2015, I also wrote my master thesis on the subject.

Sigstore is a Transparency Log intended for provenance and software artifacts which has support for a few different build artifacts. The container ecosystems also appears to be embracing it.

Cool practical example is pacman-bintrans from kpcyrd that throws Arch Linux packages on sigstore and (optionally) checks each package for being reproducible before installation.

https://github.com/kpcyrd/pacman-bintrans

https://www.sigstore.dev/

I think this is generally useful for a lot of ecosystems indeed, and it's cool to also see similar scoped projects pop up to address the these issues.

Reproducible builds are an important part of efforts to secure the software supply chain. Ideally you want multiple independent parties vouching that a given package (whether a compiled binary, or a source tarball) corresponds to a globally immutably published revision in a source code repository.

That gives you Binary Transparency, which is already being attempted in the Arch Linux package ecosystem[0], and it protects the user from compromised build environments and software updates that are targeted at a specific user or that occur without upstream's knowledge.

Once updates can be tied securely to version control tags, it is possible to add something like Crev[1] to allow distributed auditing of source code changes. That still leaves open the questions of who to trust for audits, and how to fund that auditing work, but it greatly mitigates other classes of attack.

[0] https://github.com/kpcyrd/pacman-bintrans

[1] https://github.com/crev-dev/cargo-crev

It's good that having a reproducible build process is a requirement for the Gold rating, as is signed releases.

Perhaps there needs to be a Platinum level which involves storing the hash of each release in a distributed append-only log, with multiple third parties vouching that they can build the binary from the published source.

Obviously I'm thinking of something like sigstore[0] which the Arch Linux package ecosystem is being experimentally integrated with.[1] Then there's Crev for distributed code review.[2]

[0] https://docs.sigstore.dev/

[1] https://github.com/kpcyrd/pacman-bintrans

[2] https://github.com/crev-dev/crev

> Of course, since these packages are built automatically without human supervision it’s likely that some of them will have bugs in them that would otherwise have been caught by the maintainer.

Human supervision isn't enough to protect the supply chain, and I can't think of a time that it's actually stopped an attack at the packaging stage, but having some extra "friction" in the process seems like it should be a benefit. Ideally an attacker would have to get past both the upstream author and the Debian maintainer, rather than these being two separate single points of failure.

Fortunately the Debian project is improving the situation with regards to supply chain attacks by continuing to work on Reproducible Builds. I think the next step from there needs to be Binary Transparency, with the adoption of the sort of approach being trialled by Arch Linux:

https://github.com/kpcyrd/pacman-bintrans

* having to rebuild some packages that are not part of your main OS configuration because you upgraded your main OS (e.g., Arch updates breaking AUR packages, or system upgrades breaking software you compiled manually or your Python virtualenvs, etc.). (You do have to inform the package manager that you don't want these externally-depended-on packages garbage collected, though. For Nix, for example, you can do that automagically by running fc-userscan against your project directories: https://github.com/flyingcircusio/userscan )

The statelessness is related to reproducibility in that it's a result of the functional package management approach to reproducibility. Since every version of your whole system is generated without reference to previous versions (indeed, from scratch!), the OS never has to navigate state transitions for its packages. It doesn't have to worry about converting configuration files from one format to another, or replacing defaults, or the implicit dependencies of your system undergoing name changes or being replaced. Nix and Guix don't need Debian-style transitional packages and similar tricks. That means you aren't punished, on a per-package basis, for not updating your system constantly.

For example, I recently took some neglected, non-internet-facing NixOS servers and updated them from an early 2018 release of NixOS to the latest NixOS unstable rolling release. While I did have to first work a forward incompatibility issue in Nix itself, the rest of the upgrade was a single step, and I didn't have to worry about finding a valid ‘upgrade path’.

It's worth noting that in a strict sense, the reproducibility is all still there, even for NixOS releases that no longer receive updates. If you need to use an old version of some piece of software for compatibility reasons, in a safe environment, you can use the latest and greatest Nix to install packages from NixOS releases that are 2 or 4 or 6 or 8 years old— including on top of a bleeding edge system running NixOS Unstable.

But you have a point: it would be awesome if there were long-term releases, you would get a different kind of reproducibility— one which is less strict but more useful in some ways. For example, you could take a Nix expression that someone posted in a Gist on GitHub 4 years ago, for what was back then the latest NixOS stable release. If that release were also an LTS, you could not just reproduce what they actually had, but apply it against the latest version of the same LTS to get a system that should be totally compatible in terms of behavior, but suitable for running in production without modification, thanks to up-to-date security patches.