Hacker News Reader

Comment by paulgb | Hacker News Reader

This was bound to happen. As a Chrome extension developer, I would love to have a way to prove that an extension was created from a specific git commit hash with no modifications. As it is, even if you read over the extension's code on GitHub, there is no reason not to suspect that I added something malicious when I submitted to the app store.

View on HN

This is the same problem that some package repositories like NPM have.

Everyone takes it for granted that the github link on an npmjs.com project page describes the code you get when you `npm install`.

Both npmjs.com and the Chrome app store should have an in-line file browser to make it as easy to vet the code as possible.

I have a browser plugin[0] that lets you view a Chrome plugin's source code, but I've also noticed how many of them obfuscate their code. For example, the Super Netflix plugin is heavily obfuscated: https://chrome.google.com/webstore/detail/super-netflix/aioe...

I can certainly imagine why. It would take me a non-trivial amount of time to figure out how to interact with Netflix's client/server. I gave up when I couldn't even figure out how to programmatically pause/unpause the client. And that's now the plugin's secret sauce, especially in a hostile app store where everyone is chomping at the bit to clone your plugin.

I don't know of any easy solutions here.

Even large scale manual review like Apple's approach has issues with clones.

[0]: https://chrome.google.com/webstore/detail/chrome-extension-s...

I'm pretty sure I ran across malicious Chrome plugins being mentioned before.

Eclipse and PyPy has a problem with it too[0][1].

Apple with their walled garden also isn't a panacea. They let a very glitchy and broken version of cuphead onto the app store (so much for manual review and flawless experience) and there apparently is a known repeated offender whose MO is to port popular indie desktop games (maybe because it's Unity3D games it's easy?) to iOS hastily and sell them[2]. They also only last year banned the fake anti-viruses (the "speed your phone up by clicking this red button in this free app and paying us $10 to remove 1337 north korean backdoors, viruses and unneeded programs!1" clickbait kind, the one that targets low tech people).

I also wonder how far you could maybe get with some really great game in a native executable for Windows on itchio or Game Jolt (or maybe even on Steam, they are really bad with catching broken, bad, etc. games and have a very hands off approach to everything on there) that was also packed with covert viruses/trojans, people download and run those very willy nilly on their computers, don't keep themselves up to date (thanks to Microsoft making updates obnoxious and doing crap like installing Candy Crush 325254th time, I know I removed one from my laptop like twice or thrice now) and I wonder if there is any security scanning on those sites to try detect viruses in uploaded files (I wanted to try with EICAR but it kept getting nuked by Windows Defender and I don't have the patience to try make it leave my EICAR file alone).

[0] - https://eclipse.org/org/press-release/20170814_security_bull...

[1] - https://news.ycombinator.com/item?id=15256121

[2] - https://www.polygon.com/2017/12/18/16790052/cuphead-fake-ios...

[3] - https://www.theverge.com/2017/9/15/16314034/apple-developer-...

Parent post meant PyPI not PyPy.

Yes, of course! I mistyped because the names are so close. I can't edit it anymore either. There's of course nothing specific to PyPy (or CPython or any other implementation) with being vulnerable to crap code in PyPI being pulled in by pip or something.

I also meant Chrome extensions of course, not plugins, but plugins are so rare (except the default Flash) and sidelined (even chrome://plguins no longer works) that I call extensions plugins very often.

> Both npmjs.com and the Chrome app store should have an in-line file browser to make it as easy to vet the code as possible.

A diff with an X or a check mark if it's overall different in any way would be awesome too.

Or just a way to, say, right-click on the extension after it's installed and see the hash. The you can compare.

This is exactly why ether contracts are so interesting. You can guarantee the code being executed is what you are looking at.

That's got nothing to do with ether. A simple hash of the code is just as effective (or ineffective) at proving the program is the same.

Unfortunately, in reality you quickly run into problems with different compiler versions, optimisation settings and other issues that make builds unreplicable. At least with chrome extensions you can look at the JS source. With ethereum, all you have to go on is the compiled bytecode.

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?

Why would you need a blockchain for this? Any sort of signed reproducible build would work just fine.

Because these days everything needs a blockchain.

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.

>ex. Ethereum to compile your code...

but that's just a roundabout way of doing reproducible builds.

Reproducible builds you can cryptographically verify without doing the building yourself.

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.

  Why would you need a blockchain for this?

Evil insiders.

There are two threat models:

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?

Because Moar Blockchain. Blockchain all the things!

... sorry had to post this. Quite tired of Blockchain.

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.

You just need integrity hashes and public key signatures, not a blockchain.

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.

Reply on news.ycombinator.com