Revamp the way we handle keyring access and use it to store the monero seed and the tari seed passphrase.
Motivation and Context
The user could deny access to the system Keychain, if they do we wouldn't be able to successfully store needed credentials for the app. Provide a wrapper to encapsulate storing the credentials in either the system keychain, or fallback to file IO storage.
How Has This Been Tested?
Manually
What process can a PR reviewer use to test or verify this change?
There are (at least) 7 important scenarios that need to be covered.
A new wallet is created and access to the keychain is denied
A new wallet is created and access to the keychain is granted
A new wallet is created and access to the keychain is granted, but on the next startup access to the keychain is denied
An old wallet was created access is granted (from a previous version). The wallet is upgraded to this version, granted access, and continues to work
An old wallet was created access is granted (from a previous version). The wallet is upgraded to this version, access is denied, and continues to work
An old wallet was created, and access to the keychain is denied. The wallet is upgraded to this version, access is granted, and continues to work
An old wallet was created, and access to the keychain is denied. The wallet is upgraded to this version, access is denied, and continues to work
Additional scenarios that don't require the grid:
Create a new wallet, do what you will with the password, get your monero seed words, ensure they are unique between new wallet creations. Recovery the monero wallet using the monero GUI wallet, on Mainnet. Validate the recovered wallet has the same monero address we provided.
Scenario
Old wallet Key Chain Access
New wallet Key Chain Access Denied
Unique Monero Address
Monero Seed words visible
Passed
1. New wallet, denied access
N/A
❌
✅
✅
✅ / ❌
2. New wallet, granted access
N/A
✅
✅
✅
✅ / ❌
3. New wallet, granted then denied
N/A
✅ & ❌
✅
❌
✅ / ❌
4. Old wallet, granted access, upgraded and granted access
✅
✅
❌
❌
✅ / ❌
5. Old wallet, granted access, upgraded and denied access
✅
❌
❌
❌
✅ / ❌
6. Old wallet, denied access, upgraded and granted access
❌
✅
❌
❌
✅ / ❌
7. Old wallet, granted access, upgraded and denied access
❌
❌
❌
❌
✅ / ❌
A FULL WALLET RESET, FROM THIS VERSION,
is required between each scenario
Testing Steps
Scenario 1:
Create a new wallet
When prompted for a password to access secure storage / keychain select deny, and do not enter a password
Validate you have a unique monero address
Validate you can see the monero address seed words
Scenario 2:
Create a new wallet
When prompted for a password to access secure storage / keychain enter a password correctly (however many times prompted, or select Always Allow)
Validate you have a unique monero address
Validate you can see the monero address seed words
Scenario 3:
Create a new wallet
When prompted for a password to access secure storage / keychain enter a password correctly (however many times prompted, or select Always Allow)
Validate you have a unique monero address
Restart the application
When prompted for a password deny, and do not enter a password
Attempt to view monero seed words
Receive an error because you did not provide the password
Scenario 4:
Start with an old wallet that was created in a previous version.
When prompted for a password to access secure storage / keychain enter a password correctly (however many times prompted, or select Always Allow)
Upgrade the application to the current version.
When prompted for a password to access secure storage / keychain, enter the correct password (or select Always Allow).
Wallet should continue to operate without issue.
Monero address should be the default monero community address. 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A
Monero seed words area should not be present to be viewed
Scenario 5:
Start with an old wallet that was created in a previous version.
When prompted for a password to access secure storage / keychain enter a password correctly (however many times prompted, or select Always Allow)
Upgrade the application to the current version.
When prompted for a password to access secure storage / keychain, deny access, and do not enter a password.
Wallet should still operate
Monero address should be the default monero community address. 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A
Monero seed words area should not be present to be viewed
Scenario 6:
Start with an old wallet that was created in a previous version.
When prompted for a password to access secure storage / keychain, deny access, and do not enter a password.
Upgrade the application to the current version.
When prompted for a password to access secure storage / keychain enter a password correctly (however many times prompted, or select Always Allow)
Wallet should still operate
Monero address should be the default monero community address. 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A
Monero seed words area should not be present to be viewed
Scenario 7:
Start with an old wallet that was created in a previous version.
When prompted for a password to access secure storage / keychain, deny access, and do not enter a password.
Upgrade the application to the current version.
When prompted for a password to access secure storage / keychain, deny access, and do not enter a password.
Wallet should still operate
Monero address should be the default monero community address. 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A
Monero seed words area should not be present to be viewed
Scenario 8:
Create a new wallet
When prompted for a password to access secure storage / keychain accept, or deny, dealers choice
Validate you have a unique monero address
Validate you can see the monero address seed words
Run the monero wallet GUI
Set the GUI to mainnet
Recover with seed words
Validate address matches
Breaking Changes
[x] None
[ ] Requires data directory on base node to be deleted
Description
Revamp the way we handle keyring access and use it to store the monero seed and the tari seed passphrase.
Motivation and Context
The user could deny access to the system Keychain, if they do we wouldn't be able to successfully store needed credentials for the app. Provide a wrapper to encapsulate storing the credentials in either the system keychain, or fallback to file IO storage.
How Has This Been Tested?
Manually
What process can a PR reviewer use to test or verify this change?
There are (at least) 7 important scenarios that need to be covered.
Additional scenarios that don't require the grid:
A FULL WALLET RESET, FROM THIS VERSION, is required between each scenario
Testing Steps
Scenario 1:
Scenario 2:
Scenario 3:
Scenario 4:
44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A
Scenario 5:
44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A
Scenario 6:
44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A
Scenario 7:
44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A
Scenario 8:
Breaking Changes