karalabe

This repository is an unofficial fork of `github.com/ipfs/go-ipfs`, converted from a `gx` based project to a plain Go project. The goal is to act as an IPFS library that can be imported and used from Go apps without the need of switching all dependency management over to `gx`. As a bonus, this fork is compatible with GoDoc!

Was fixed 2 months ago https://github.com/ethereum/go-ethereum/pull/15962

TL;DR Geth 1.8.0 shipped with [DSN rebind protection](https://github.com/ethereum/go-ethereum/pull/15962), so as far as we know, it's not vulnerable.

---

We originally rejected the bounty report because:

* We always recommend people communicate with Geth via IPC, not HTTP. The APIs are too powerful for public access: even if noone can steal your Ether, they can exhaust all your local resources via eth_call for example. Our suggestion is to always run a custom proxy that properly rate limits and authenticates outside users vs. running an HTTP server inside Geth. CORS is a protection that always depends on browsers correctly enforcing it, which have been circumvented multiple times, so it's not a good enough security measure. * For a very long time now, we considered unlocking an account a dangerous operation recommended only to power users who can properly protect their setup. Mist and other applications transact via API endpoints that do not unlock accounts, so unless a user explicitly manually unlocks their account, they should be fine.

That being said... even though we consider the attack vector fairly convoluted and would require a lot of bad user practices to pull off; we agreed that if we can do anything meaningful to prevent it, then we should most definitely do that. For that reason we introduced the `--rpcvhosts` flag which is similar to CORS, but checks the requests origin via different means, and rejects DNS rebound HTTP actions server side.

As for the original report, although we rejected the bounty request initially, we agreed that it should be rewarded with a low-impact value since we did make a software modification based on the report. Unfortunately this bounty decision is waiting for approval since the 5th of February. Not sure why it got stuck in the pipeline, we apologize for the delay.

Ethereum doesn't aim to store massive data within the blockchain itself. Instead, we're building an additional component into the network, Swarm, which essentially acts as a DHT/DFS. There are already experimental branches within the main repos, they function, but probably at a POC state.

Furthermore, a 1Gbit DL/200Mbit UL link costs $13.70/month where I live, so I think it it is already very much viable, but maybe the distribution will be skewed towards more internet friendly countries :)

Without wanting to sound too plain/blunt, as much as I like working on Iris and giving it to the community for free, I also need to make a living. Hence why I am looking for a backer, to be able to continue it.

On another note, the project is getting quite large with a lot of different things to work on, but I'm a single person with limited time. So while financial support is nice, I'm also open to possibilities of taking Iris under the umbrella of a corporation which would have the necessary expertise to really expand it.

Yes, the point with the package naming was to convey some additional information (i.e. erlclient, goserver, etc) to keep the snippet size down. I think they are understandable and workable as is, but nontheless you are perfectly right with your concern so I might update them at some point :)

Iris was written in Go (with a few platform speficit C snippets) and is available for Linux, OSX, Windows and 32bit/64bit/arm :)

You can download pre-built binaries from http://iris.karalabe.com/downloads (or of course you can compile from source https://github.com/project-iris/iris)

Since Iris was/is my PhD work, and is currently not funded, I decided to release it under GPL to retain some control over what people end up doing with it (by no means do I want to prevent adoption, hence the dual licensing escape clause).

Nonetheless I'm open to discussing other OSS licenses such as BSD or Apache, but I think such issues are a bit further down the road :)