pacman-bintrans VS webext-signed-pages

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

There is "Signed Pages" by the debeloper of EteSync. It is a browser extension, that checks webapps based on signatures in the html file. The addon then warns the user if the signature is not correct or - if I remember correctly - the source changed. This allows you to be sure what webapp code was delivered. But it seems like it did not really get used outside of his own projects. https://github.com/tasn/webext-signed-pages

EteSync has implemented something called Signed Pages, this might be worth looking closer at. This uses PGP keys which is preloaded into the browser; but I suspect that will be a barrier too high for most non-tech users.

There are also projects like signed web pages which can also help increasing the trust level to some degree. But that requires that you can download the source code and regenerate the verification hash locally - or have other trusted methods to verify the hash value hasn't been modified as well. The current concept is reasonably sane, but it requires too much from users currently to make it widely used.

> The server can at any time start serving malicious payloads

True, and I call this threat model "Beware Each and Every Fetch" (BEEF) in contrast to the more common TOFU model (although if you trust a desktop app to auto-update itself then these two models might not be all that different).

In any case, I think you're being a little quick to dismiss the idea of server-hosted applications. It's true that browsers don't natively have a nice way of pinning specific versions of a web app, but there is the clever hack of SecureBookmarks[0] (if you're prepared to sacrifice the UX), or, more realistically, you can pin the web app version using some sort of browser extension.

Examples of the latter include the Signed Pages extension[1], and Code Verify[2], which is the result of a collaboration between Meta and Cloudflare (for securing the WhatsApp Web code, currently, but should eventually support other sites like Proton's too). Of course, it would be much better if this capability was natively included in browsers themselves, but hopefully adoption of this technology will pressure browsers and standards bodies to take ownership of this.

[0] https://coins.github.io/secure-bookmark/

[1] https://github.com/tasn/webext-signed-pages

[2] https://github.com/facebookincubator/meta-code-verify

Something like a browser extension for this does already exist, fortunately:

https://github.com/tasn/webext-signed-pages

In regards to untrusted webapp, yes, that is a reasonable attack vector. That said, I've heard from ProtonMail they have been considering to implement Signed Pages to help mitigate (at least some of the) issues with this attack vector.

Which is why it is important to get proper E2E encryption on e-mail, where the source is open source and can be audited. And then that there are verify mechanisms to verify that the source code has not been manipulated. For web services there are signed-pages which is quite interesting.