CLI wallet: avoid directly overwriting wallet file on exit #1109

[cogutvalera]

PR for #1109

[abitmore]

The logic looks fine, although naming new file as ".backup" is not so good.

[pmconrad]

AFAICS fc::ofstream does not throw nor otherwise communicate failure on write(), flush() or close().

[cogutvalera]

we should create another issue for fc::ofstream IMHO

[abitmore]

AFAICS fc::ofstream does not throw nor otherwise communicate failure on write(), flush() or close().

It means we need to make sure the new (tmp) file is good before calling fc::rename, otherwise it's still possible to lose data. @cogutvalera creating a new issue is fine, but I think this issue/PR depends on the fix of it.

[cogutvalera]

review lost commits, now checking tmp wallet file contents to be equal as required data before renaming this tmp wallet file

[pmconrad]

This is not necessary, because it already happens in the outer try/catch.

[cogutvalera]

Why it is not necessary ? I've tested & checked it and we won't get into outer try/catch code after throwing exception here that's why I've placed disable_umask_protection

[pmconrad]

Using throw without specifying an exception is only allowed in a catch clause, otherwise it will terminate instead of actually throwing, see below.

[cogutvalera]

yes, you're absolutely right ! I've checked it earlier, that's why I told you that disable_umask_protection is necessary there before using throw, if I will change throw to fc::exception subtype then I will remove disable_umask_protection call. Just couldn't understand why you told that disable_umask_protection isn't necessary before using throw.

[pmconrad]

Please throw an fc::exception subtype with an appropriate error message.

[cogutvalera]

Then we also need to throw fc::exception subtype in outer try/catch block ? right ?

[pmconrad]

no, the outer catch should re-throw whatever it caught.

[cogutvalera]

yes sure, already done without any changes in outer try/catch block

[cogutvalera]

rebased already

[abitmore]

Travis-CI complains:

2393592ms th_a main.cpp:597 test_method ] e.to_detail_string(): 0 exception: unspecified
wallet file cannot be saved
{}
th_a wallet.cpp:824 save_wallet_file
2393594ms p2p thread.cpp:252 exec ] thread canceled: 9 canceled_exception: Canceled
cancellation reason: [none given]
{"reason":"[none given]"}
p2p thread_d.hpp:473 start_next_fiber
2393594ms th_a db_management.cpp:206 close ] Rewinding from 0 to 0
unknown location(0): fatal error in "account_history_pagination": unknown type
/home/travis/build/bitshares/bitshares-core/tests/cli/main.cpp(545): last checkpoint

[abitmore]

Perhaps the Travis-CI environment has different read behavior or limitations? See #1203 (comment) for similar error.

[cogutvalera]

going to check ... Thanks !

[abitmore]

I'm playing https://github.com/bitshares/bitshares-core/blob/travis-test1/.travis.yml to check if it's related to disk space.

[cogutvalera]

wow ! Thanks a lot ! I'm appreciate all your efforts !

[abitmore]

Not a disk space issue.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.7G  4.0K  3.7G   1% /dev
tmpfs           748M  300K  748M   1% /run
/dev/sda1        30G   18G   11G  62% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            3.7G     0  3.7G   0% /run/shm
none            100M     0  100M   0% /run/user
none            768M  179M  590M  24% /var/ramfs

[cogutvalera]

1955015ms th_a       wallet.cpp:799                save_wallet_file     ] saving wallet to file wallet.json
1955016ms th_a       wallet.cpp:817                save_wallet_file     ] saved successfully wallet to tmp file wallet.json.tmp
1955016ms th_a       wallet.cpp:823                save_wallet_file     ] validated successfully tmp wallet file wallet.json.tmp
1955016ms th_a       wallet.cpp:827                save_wallet_file     ] renamed successfully tmp wallet file wallet.json.tmp
1955017ms th_a       wallet.cpp:834                save_wallet_file     ] successfully saved wallet to file wallet.json

[pmconrad]

Question: If saving fails, should the error message contain the JSON representing the wallet file? That might give the user another chance to save the data in an emergency situation, perhaps by screen-scraping it.

[abitmore]

@pmconrad makes sense.

[cogutvalera]

#1171 issue concerns about showing any secrets on console, so what is the best approach ? but I also agree with @pmconrad about his idea, it really makes sense and @abitmore was agreed too, let's decide the best approach to be applied everywhere the same way

[abitmore]

Wallet file contains no secret. No password, no plain private key.

[cogutvalera]

just for the info wallet file contains next info:

{ "chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8", "my_accounts": [], "cipher_keys": "b30a0ede652bfb2d8d99f8aca77ff8c089f07d77bd047c6df526bc6a652378ed5c37fbbf1d46c408ac1970aec20e83004aee339f1c81e56c0300b00f98f8c142aaad737ddbf7293d339367127a569b1e", "extra_keys": [], "pending_account_registrations": [], "pending_witness_registrations": [], "labeled_keys": [], "blind_receipts": [], "ws_server": "wss://node.bitshares.eu", "ws_user": "", "ws_password": "" }

so no secret is here, just encrypted keys and empty "ws_password" field:

_wallet.cipher_keys = fc::aes_encrypt( data.checksum, plain_txt );

[cogutvalera]

but what about "ws_password" field ? isn't it secret ?

[cogutvalera]

in my case "ws_password" field is empty so it isn't secret, but it won't always be empty, otherwise we don't need the field that will be always empty

[abitmore]

I'd say, remove the password before dumping.

[pmconrad]

&_wallet can never be null. It's a struct member of *this.

[cogutvalera]

it fixed travis error with violation memory access in cli_test as was before, strange behavior of travis that's why I've added this check

[pmconrad]

The travis error is unrelated, please undo this change.

[cogutvalera]

ok sure

[abitmore]

This is still not ready yet. Pushing to next release.

[cogutvalera]

can we merge this PR and close related issue ? or this is not still ready and need some changes and improvements ? if YES, then which changes and improvements in your opinion ?

Thanks !

[pmconrad]

Thanks!