Parity-ethereum: Using a password file

[Netherdrake]

I'm running:

• Which Parity version?: 1.8.5b
• Which operating system? MacOS
• How installed?: homebrew

Issue

Unable to unlock parity with a password file.

~/G/tmp % parity --light --chain=ropsten \
          --unlock 0xaaf3ffee9d4c976aa8d0cb1bb84c3c90ee6e9118 \
          --password /Users/user/Github/tmp/unlock.txt \
          --bootnodes "enode://20c9ad97c081d63397d7b685a412227a40e23c8bdc6688c6f37e97cfbc22d2b4d1db1510d8f61e6a8866ad7f0e17c02b14182d37ea7c3c8b9c2683aeb6b733a
[email protected]:30303,enode://6ce05930c72abc632c58e2e4324f7c7ea478cec0ed4fa2528982cf34483094e9cbc9216e7aa349691242576d552a2a56aaeae426c5303ded677ce455ba1acd9d
@13.84.180.240:30303" \
          --jsonrpc-apis=all --ui-port 8080 ui
2018-01-02 14:22:49  Starting Parity/v1.8.5-beta-54bae9a-20171228/x86_64-macos/rustc1.22.1
2018-01-02 14:22:49  Keys path /Users/user/Library/Application Support/io.parity.ethereum/keys/Ropsten
2018-01-02 14:22:49  DB path /Users/user/Library/Application Support/io.parity.ethereum/chains/test/db/ae90623718e47d66
2018-01-02 14:22:49  Path to dapps /Users/user/Library/Application Support/io.parity.ethereum/dapps
2018-01-02 14:22:49  Running in experimental Light Client mode.
--bootnodes Unable to read password file. Ensure it exists and permissions are correct.
~/G/tmp % cat /Users/user/Github/tmp/unlock.txt
secret_password_here
~/G/tmp %

[5chdn]

Yes, this is annoying. Try to put --password as last argument.

[tomusdrw]

or use --password=/Users/user/Github/tmp/unlock.txt

[tomusdrw]

IMHO It's actually not a bug since help states that you can provide many --password files.

[5chdn]

But a space should separate cli options and not password files...

[asymmetric]

Would it make sense to expect a comma between password files?

[axelchalon]

I agree that this is not intuitive and that the launch options in the first post should have been parsed differently.

Currently all the arguments share the same parsing options, and one of those enabled options is that values that are delimited from the option by a space can still start with hyphens. This allows running parity --allow-ips -10.0.0.0/8 for example. The downside is that for options that can take multiple values, since multiple values are also separated with a space, any subsequent argument is treated as a value (hence this issue).

To fix this, we can either disable the hyphen option, i.e. only allow values to start with hyphens when the value (or list of values) is delimited from the option name with = (e.g. parity --allow-ips -10.0.0.0/8 won't work, but parity --allow-ips=-10.0.0.0/8 still will). Or we could set the comma as the only valid value delimiter (--password=value1 value2 won't work any longer; --password=value1,value2 will be the new syntax).
First option seems best to me. What do you think?

[5chdn]

Or we could set the comma as the only valid value delimiter

Yes, please. I'm not sure why --password value1 value2 is desired in the first place.

[asymmetric]

I'd be happy to take care of this.

[axelchalon]

note that setting multiple password files by using --password file1 --password file2 also works

@asymmetric thanks for you interest! however since there's already a pending PR on the CLI and this is a small fix, I figured it was simpler to include it in my PR: https://github.com/paritytech/parity/pull/7626