feat: add an option to configure owner_api address and port

[squarfed]

Currently grin wallet owner_api listen address is hardcoded to 127.0.0.1:13420. This PR adds the option to configure the listen address and port in the grin-wallet.toml file.

This is required for web and mobile wallets that need to query the api remotely.

[yeastplume]

Thanks for the PR! The wallet owner api is hardcoded to localhost intentionally, as (at least in its current form) it has the potential to be a massive security problem. So much so that we only allow it to exist if and only if it’s localhost only.

Of course this may change in future with some focus on how to expose these functions securely, but at the moment we don’t even want to open up the possibility of allowing someone to misconfigure it via the config file. If someone really wants it at the moment they can change it in their own fork, this way there can be no argument that it was accidental or the person didn’t know what they’re doing

[squarfed]

I thought it must have been discussed in the past. However the main security issue is that the api secret is exposed to man in the middle attack. Wouldn't allowing only https connections solve the problem?

I would like to develop an open source mobile wallet and the feature is essential.

[garyyu]

@PositronicBrain an open source mobile wallet? 😄 I love it. Is it started?

[ignopeverell]

@PositronicBrain Allowing only https isn't something we can enforce, hence the accent on forking to tweak that to your needs. It seems you'd want to have your own fork anyway? Or did you want your mobile to connect to a users' existing grin instance?

[squarfed]

Or did you want your mobile to connect to a users' existing grin instance?

@ignopeverell yes the idea is to allow a user to connect to his own grin instance from outside localhost.

In this sense I meant https can be enforced, if that's the only type of protocol that is exposed to the outside network.

It seems you'd want to have your own fork anyway?

No, the problem can be solved with a local proxy too, only it is more cumbersome.

@garyyu thanks, we will release the source as soon as we have something consistent going.

[ignopeverell]

HTTPs in itself doesn't give much, we'd need an authentication protocol. And you'd probably need certificate pinning as well.

[squarfed]

This is what I was thinking:

• The server generates a self-signed certificate
• The server passes the certicate and the api secret to the wallet on a side channel
• From now on the client uses the certificate to establish an https secure connection and authenticates with the api secret.

Unfortunately the last part (using the self signed certificate) is simple conceptually but not straightforward from a technical point of view, at least using react-native libraries.

[ignopeverell]

Have you given some thoughts to just embedding Grin on mobile?

[squarfed]

That would be the idea in the long run, but it's an order of magnitude more complex.

I wanted to start with something simple, and a wallet connecting through rest calls to your own full node would give the strongest security model right from the start, at the expense of simplicity of setup for the end user of course. I think it would have adopters.

Next we could embed the keys and build transactions in the wallet itself, but this is something I have not yet given much thought. Eventually could we have a full node running in the mobile? I am not sure if that's feasible, I am still working to understand all the details of Grin.

[sesam]

is grin for Android (ARM) ready to be built and embedded?

[mfronczyk]

I've quickly tried to create an iOS static library from the grin_servers crate that exposes a single grin_start_server() function but I failed to run it. I managed to create the static lib (after solving few issues), but I didn't manage to start the node on the device.

I also tried running grin tests on the device as well, but they panicked with an error like this:

---- data_files stdout ----
thread 'data_files' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

It's probably required to change network handling and filesystem access to be able to run on restricted iOS environment.

I'm not sure whether a separate implementation should be started for mobile/ARM node & wallet or some parts of grin could be extracted into a reusable lib containing crypto, chain and protocol handling , letting the client handling network and data storage. Any thoughts about what makes more sense? I'm not sure how deeply grin assumes to be run on servers/desktops.

[hashmap]

I'm closing this PR, let me know if needs more discussion