Is there anything from a developer perspective that we could do now? I guess anything thats voluntary could be bypassed by a malicious party either way. Reproducibile builds published in a blockchain? Then a chrome plugin that only loads the blockchain builds?
Legitimately, if you used ex. Ethereum to compile your code could actually prove that a given executable was compiled from given source. Otherwise the only way to verify a build is to build it yourself and check the hashes. Signing just verifies that the build came from a given person, not that they used the source code they say they did.
This was one of the interesting use cases I thought about when I dug into crypto.
The signature doesn't have to be from the developer; it could be a signature from google that marks the extension was compiled from/matches the specified source. If you're running chrome and installing extensions from the chrome web store you're trusting google already.
As evinced by the article, the web store isn't perfectly trustworthy but this kind of validation could be done automatically and I do trust their ability to automate.
If Google compiled the extensions that would work. Seems like it would take a lot of standardization to make that possible. But in principle that would certainly be better than the current situation.
How would this work on a blockchain? The best I could come up with is "check that a bunch of other nodes built it and came up with the same result", or "use a trusted execution environment (SGX or TZ) to build it".
One expensive way that would work would be to write a compiler in Solidity. There might be better ways involving breaking up the code and splitting it up between compute resources like on Golem. By the standards of common blockchain cryptographic security I'm pretty skeptical of SGX and the like.
So if you could build a perfectly efficient compiler that did not create any additional overhead, if the normal compilation took about a second or two (or any longer) to run locally. Then you would run waaay over the gas limit.
That also means such a thing would cost way more than 10 dollars to run.
Yeah, super expensive for sure. But in principle possible - I'm sure there are smarter ways to do it. I could also see some users willing to pay ~$1K or more. A big company committed to high-security, open source firmware for their routers, for example, could benefit a lot by being able to demonstrate to their customers that they use a given (ideally highly readable for auditing purposes) source code and that the updates they receive really use that source. I don't think there's a means to enable that sort of cryptographic verification currently without every interested end user rebuilding the source.
One place to look up all hashes, identities attached, transactions are in order, the API is the same for all hashes no matter the store or the tech, it can work offline, if the site is down or under attack you can still check, it avoids putting loads on the original site, it's more resilient to attacks.
Having one homogeneous decentralized way to read this data is neat. You could make entire package managing solution out of this. Even attach torrent magnet links for each lib in the chain, and make the whole store distributed.
A git repository or a torrent or any other distributed datastore would also accomplish this. A blockchain is a very bad, expensive distributed datastore that you would only use if you need the specific trust properties it provides.
It would be a fair point to say that if you don't trust any specific person or entity to verify that a given source compiles to the binary signed by the author that maybe some sort of blockchain would be useful. I think you'd get a lot more bang for your buck by using trusted authorities in something closer to a CA model.
The advantage of the blockchain is that we have well tested clients and api already, dealing with ID, logs and sync, with a huge number of nodes.
And you do need trust for distributing software.
You can't use git, it's hard to sync automatically. Torrent is a nice transport, not a db, and can be use to sync blockchains anyway, why make them exlusive ? And using any distributed db would exclude the field tested solution on millions of wallet that prove to work, and the api that is alreay well supported.
1. Evil Foreign Spy infiltrates the Tor project and makes a backdoored, signed release.
Evil Foreign Government uses MITM or something similar to serve this backdoored version to one or two journalists they know aren't technical enough to inspect the source code themselves.
The journalists think "This will be safe, as it will have been code reviewed by people who know how to do that" but no such people ever saw the backdoored version.
Hence, you don't just need a signed build - you also need a globally-agreed list of builds, so the user (and the auto-update mechanism) can be sure everyone else in the world knows this release exists. If a build is ever repudiated, sound the alarm!
2. Evil Foreign Spy infiltrates the Tor project, and intentionally triggers the alarm in a way that doesn't lead back to them.
The alarm going off and the fact the infiltrator hasn't been found means people don't trust Tor, or they start ignoring the alarm rendering it useless.
Hence, you don't just need a globally-agreed list of builds - you need an indestructible, globally-agreed copy of each build's source code and who changed each line.
Now granted, a blockchain isn't the only way to achieve these things - indeed, it'd cost a fortune to put the entire Tor source code into the Bitcoin blockchain - but you need some similar mechanism.
If you have a malicious government with private keys MITM-ing your connection, how can you trust the list of builds? Couldn't they have faked consensus for that as well?
Unfortunately I think the best option currently is to download and build open-source extensions yourself and add them in developer mode, but Chrome will bother you about running developer extensions every time you start the browser so that's not ideal.
My own strategy is just to limit the number of extensions I use to a small number of ones from established/trusted entities, but it pains me because I publish a couple extensions and I am not an established entity.
blockchain + ipfs, sign an ipfs address with some kind of blockchain address. Though this still ends up with all the issues of verifying identity that you have with normal certificate authorities.
