chia-blockchain
chia-blockchain copied to clipboard
Optional[Credential] = keyring.get_credential(keychain_service, current_user) -> AttributeError: 'NoneType' object has no attribute 'get_credential'
OS: Freebsd 13.1(TrueNAS), using a jail
I currently have 1.5.0 working in this jail and wanted to update to the latest, so I created a new directory and cloned the latest release and did the following build steps. When I try to start the services and enter my passphrase I get this traceback. In the previous 1.5.0 install the passphrase seems to work correctly and I do not get this traceback. I'm not sure if I'm missing a step because it's freebsd or if this is a bug, kinda seems like a bug to me?
Build steps:
- git clone https://github.com/Chia-Network/chia-blockchain.git -b latest
- cd chia-blockchain
- python3 -m venv venv
- source venv/bin/activate
- pip install --upgrade pip
- pip install clvm-tools-rs maturin (also tried clvm-tools-rs==0.1.19)
- bash ./install.sh
- chia init
CMD: chia start farmer
Traceback (most recent call last):
File "/root/chia-1.5.1v2/chia-blockchain/venv/bin/chia", line 8, in <module>
sys.exit(main())
File "/root/chia-1.5.1v2/chia-blockchain/chia/cmds/chia.py", line 147, in main
cli() # pylint: disable=no-value-for-parameter
File "/root/chia-1.5.1v2/chia-blockchain/venv/lib/python3.9/site-packages/click/core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "/root/chia-1.5.1v2/chia-blockchain/venv/lib/python3.9/site-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/root/chia-1.5.1v2/chia-blockchain/venv/lib/python3.9/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/root/chia-1.5.1v2/chia-blockchain/venv/lib/python3.9/site-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/root/chia-1.5.1v2/chia-blockchain/venv/lib/python3.9/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
File "/root/chia-1.5.1v2/chia-blockchain/venv/lib/python3.9/site-packages/click/decorators.py", line 21, in new_func
return f(get_current_context(), *args, **kwargs)
File "/root/chia-1.5.1v2/chia-blockchain/chia/cmds/start.py", line 17, in start_cmd
asyncio.run(async_start(root_path, config, group, restart, ctx.obj["force_legacy_keyring_migration"]))
File "/usr/local/lib/python3.9/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 647, in run_until_complete
return future.result()
File "/root/chia-1.5.1v2/chia-blockchain/chia/cmds/start_funcs.py", line 68, in async_start
if not await migrate_keys(root_path, True):
File "/root/chia-1.5.1v2/chia-blockchain/chia/cmds/keys_funcs.py", line 221, in migrate_keys
legacy_keyring = Keychain(force_legacy=True)
File "/root/chia-1.5.1v2/chia-blockchain/chia/util/keychain.py", line 219, in __init__
KeyringWrapper.get_legacy_instance() if force_legacy else KeyringWrapper.get_shared_instance()
File "/root/chia-1.5.1v2/chia-blockchain/chia/util/keyring_wrapper.py", line 187, in get_legacy_instance
return KeyringWrapper(force_legacy=True)
File "/root/chia-1.5.1v2/chia-blockchain/chia/util/keyring_wrapper.py", line 115, in __init__
if check_legacy_keyring_keys_present(legacy_keyring):
File "/root/chia-1.5.1v2/chia-blockchain/chia/util/keyring_wrapper.py", line 58, in check_legacy_keyring_keys_present
credential: Optional[Credential] = keyring.get_credential(keychain_service, current_user)
AttributeError: 'NoneType' object has no attribute 'get_credential'
Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x8047cdd00>
Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x8047cc0d0>
Some more info from the build if it helps?
Successfully built chia-blockchain aiohttp blspy chia-rs chiabip158 chiapos chiavdf cryptography PyYAML setproctitle zstd frozenlist
multidict yarl pycryptodome argon2-cffi-bindings Installing collected packages: zstd, sortedcontainers, dnslib, chia-rs, bitstring,
zipp, watchdog, typing-extensions, setproctitle, PyYAML, pyparsing, pycryptodome, pycparser, portalocker, multidict, idna, frozenlist,
filelock, dnspython, colorlog, colorama, click, chiavdf, chiapos, chiabip158, charset-normalizer, blspy, attrs, async-timeout, aiofiles,
yarl, packaging, importlib-metadata, concurrent-log-handler, clvm, cffi, aiosqlite, aiosignal, keyring, cryptography, clvm-tools,
argon2-cffi-bindings, aiohttp, argon2-cffi, keyrings.cryptfile, chia-blockchain
Successfully installed PyYAML-6.0 aiofiles-0.7.0 aiohttp-3.8.1 aiosignal-1.2.0 aiosqlite-0.17.0 argon2-cffi-21.3.0
argon2-cffi-bindings-21.2.0 async-timeout-4.0.2 attrs-22.1.0 bitstring-3.1.9 blspy-1.0.13 cffi-1.15.1 charset-normalizer-2.1.1
chia-blockchain-1.5.1 chia-rs-0.1.5 chiabip158-1.1 chiapos-1.0.10 chiavdf-1.0.6 click-7.1.2 clvm-0.9.7 clvm-tools-0.4.5
colorama-0.4.5 colorlog-6.6.0 concurrent-log-handler-0.9.19 cryptography-36.0.2 dnslib-0.9.17 dnspython-2.2.0
filelock-3.7.1 frozenlist-1.3.1 idna-3.3 importlib-metadata-4.12.0 keyring-23.6.0 keyrings.cryptfile-1.3.4 multidict-6.0.2
packaging-21.3 portalocker-2.5.1 pycparser-2.21 pycryptodome-3.15.0 pyparsing-3.0.9 setproctitle-1.2.3
sortedcontainers-2.4.0 typing-extensions-4.3.0 watchdog-2.1.9 yarl-1.8.1 zipp-3.8.1 zstd-1.5.0.4
Chia blockchain install.sh complete.
For assistance join us on Keybase in the #support chat channel:
https://keybase.io/team/chia_network.public
Try the Quick Start Guide to running chia-blockchain:
https://github.com/Chia-Network/chia-blockchain/wiki/Quick-Start-Guide
To install the GUI type 'sh install-gui.sh' after '. ./activate'.
Type '. ./activate' and then 'chia init' to begin.
Doing a quick edit to force the check for legacy keys to false allows for the services to startup. I didn't dig any deeper but it seems like the way force_legacy gets set to True is incorrect.
diff --git a/chia/util/keyring_wrapper.py b/chia/util/keyring_wrapper.py
index 6a1f346d3..4d2545a06 100644
--- a/chia/util/keyring_wrapper.py
+++ b/chia/util/keyring_wrapper.py
@@ -110,6 +110,7 @@ class KeyringWrapper:
from chia.util.errors import KeychainNotSet
self.keys_root_path = keys_root_path
+ force_legacy = False
if force_legacy:
legacy_keyring = get_legacy_keyring_instance()
if check_legacy_keyring_keys_present(legacy_keyring):
Ok, learning as I go here. looks like the ~/.chia_keys/.checked_legacy_migration file is empty and if you put False in there it gets picked up for the config(ctx.obj["force_legacy_keyring_migration"]) and sets the legacy value to false at startup.
I assume someone knows how this is supposed to work, is this a config file you need to manually set? That seems strange.
EDIT: on my test system it looks like the .checked_legacy_migration file exists and is empty on my live system there is no .checked_legacy_migration file. Now sure why that is.
The issue in your first comment is caused by get_legacy_keyring_instance()
returning None
. Looking at the implementation, you could try changing the elif platform == "linux":
to else:
and see if that helps. FreeBSD isn't officially supported, but it should generally work assuming this is the issue.
if platform == "darwin":
return MacKeyring()
elif platform == "win32" or platform == "cygwin":
return WinKeyring()
elif platform == "linux":
keyring: CryptFileKeyring = CryptFileKeyring()
keyring.keyring_key = "your keyring password"
return keyring
return None```
@paninaro It seems like that chunk of code is the same in 1.5.0 and 1.5.1. In 1.5.0 it prompts for the keyring passphrase when starting up I assume it's working correctly. In 1.5.1 it doesn't prompt and just gives an error message. Do you know if any of the changes for the keyring migration might have caused this problem?
Switching the elif case to include freebsd does solve the problem as well. But it no longer asks me for a passphrase. I'm not sure the implications are for that.
In 1.5.1 we started deprecating the legacy keyring, so that's why you're being prompted to migrate those keys now -- it's no longer optional. If the keyring migration step doesn't identify any keys that need to be migrated, then you should. be in good shape. All current keys should be in ~/.chia_keys/keyring.yaml
It does sound a bit odd that you're not being prompted for your keyring passphrase... When in doubt, run chia keys show
to make sure that your keys are what you expect them to be.
I'm also interested to know why it seems to be working just fine in 1.5.0. Seems like maybe that get_legacy_keyring_instance isn't getting called in the 1.5.0 version?
Also I don't think it's prompting for a passphrase because it's using the legacy keyring, right? In the keyring_wrapper.py file the else condition for linux/freebsd just gets the passphrase in the code as a string right there.
ok maybe I see what is happening. The code that is getting hit in 1.5.1 was not being used in 1.5.0 unless you tried to run chia keys migrate. So this problem was always there but you had to try and run the migration to hit it. I'm not sure why in 1.5.1 it's trying to do the migration even though there are no legacy keys? And even then it seems migration is broken for freebsd. :(
chia 1.5.0 output
(venv) [root@chia-farmer ~/chia-blockchain/chia]# chia keys migrate
Traceback (most recent call last):
File "/root/chia-blockchain/venv/bin/chia", line 33, in <module>
sys.exit(load_entry_point('chia-blockchain', 'console_scripts', 'chia')())
File "/root/chia-blockchain/chia/cmds/chia.py", line 150, in main
cli() # pylint: disable=no-value-for-parameter
File "/root/chia-blockchain/venv/lib/python3.9/site-packages/click/core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "/root/chia-blockchain/venv/lib/python3.9/site-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/root/chia-blockchain/venv/lib/python3.9/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/root/chia-blockchain/venv/lib/python3.9/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/root/chia-blockchain/venv/lib/python3.9/site-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/root/chia-blockchain/venv/lib/python3.9/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
File "/root/chia-blockchain/venv/lib/python3.9/site-packages/click/decorators.py", line 21, in new_func
return f(get_current_context(), *args, **kwargs)
File "/root/chia-blockchain/chia/cmds/keys.py", line 155, in migrate_cmd
migrate_keys()
File "/root/chia-blockchain/chia/cmds/keys_funcs.py", line 194, in migrate_keys
keys_to_migrate, legacy_keyring = Keychain.get_keys_needing_migration()
File "/root/chia-blockchain/chia/util/keychain.py", line 570, in get_keys_needing_migration
legacy_keyring: Keychain = Keychain(force_legacy=True)
File "/root/chia-blockchain/chia/util/keychain.py", line 247, in __init__
KeyringWrapper.get_legacy_instance() if force_legacy else KeyringWrapper.get_shared_instance()
File "/root/chia-blockchain/chia/util/keyring_wrapper.py", line 207, in get_legacy_instance
return KeyringWrapper(force_legacy=True)
File "/root/chia-blockchain/chia/util/keyring_wrapper.py", line 120, in __init__
if check_legacy_keyring_keys_present(legacy_keyring):
File "/root/chia-blockchain/chia/util/keyring_wrapper.py", line 63, in check_legacy_keyring_keys_present
credential: Optional[SimpleCredential] = keyring.get_credential(keychain_service, current_user)
AttributeError: 'NoneType' object has no attribute 'get_credential'
This issue has not been updated in 14 days and is now flagged as stale. If this issue is still affecting you and in need of further review, please comment on it with an update to keep it from auto closing in 7 days.
Yeah this is still a problem. Does anyone know how they are checking for legacy keys? I suspect the check is doing something incorrectly and causes this code to be executed every time at startup even when you don't have legacy keys.
Sure seems like it does the trick to me. I vote open a PR for this fix. @alvistar you want to give it a try?
ignore my bad naming of the directory i just reused a path i had with a recent clone of the repo which is 1.6.0
(venv) [root@tmp ~/chia-1.5.1/chia-blockchain]# uname -a
FreeBSD tmp 13.1-RELEASE-p1 FreeBSD 13.1-RELEASE-p1 n245406-814eb095751 TRUENAS amd64
(venv) [root@tmp ~/chia-1.5.1/chia-blockchain]# chia version
1.6.0
(venv) [root@tmp ~/chia-1.5.1/chia-blockchain]# chia keys migrate
No keys need migration
(venv) [root@tmp ~/chia-1.5.1/chia-blockchain]# chia keys generate
Generating private key
Added private key with public key fingerprint 3369457685
Setting the xch destination for the farmer reward (1/8 plus fees, solo and pooling) to xch1uk2sjmuylrm07qul7vwf5mu8jnunafugyums3v0v5zldqdaey0yqre057r
Setting the xch destination address for pool reward (7/8 for solo only) to xch1uk2sjmuylrm07qul7vwf5mu8jnunafugyums3v0v5zldqdaey0yqre057r
To change the XCH destination addresses, edit the `xch_target_address` entries in /root/.chia/mainnet/config/config.yaml.
(venv) [root@tmp ~/chia-1.5.1/chia-blockchain]# chia keys migrate
No keys need migration
(venv) [root@tmp ~/chia-1.5.1/chia-blockchain]# chia start farmer
Daemon not started yet
Starting daemon
chia_harvester: started
chia_farmer: started
chia_full_node: started
chia_wallet: started
(venv) [root@tmp ~/chia-1.5.1/chia-blockchain]# chia stop farmer
chia_harvester: Stopped
chia_farmer: Stopped
chia_full_node: Stopped
chia_wallet: Stopped
(venv) [root@tmp ~/chia-1.5.1/chia-blockchain]# git diff
diff --git a/chia/util/keyring_wrapper.py b/chia/util/keyring_wrapper.py
index 6a1f346d3..3ae72a3cb 100644
--- a/chia/util/keyring_wrapper.py
+++ b/chia/util/keyring_wrapper.py
@@ -112,7 +112,7 @@ class KeyringWrapper:
self.keys_root_path = keys_root_path
if force_legacy:
legacy_keyring = get_legacy_keyring_instance()
- if check_legacy_keyring_keys_present(legacy_keyring):
+ if legacy_keyring is not None and check_legacy_keyring_keys_present(legacy_keyring):
self.keyring = legacy_keyring
else:
self.refresh_keyrings()
This issue has not been updated in 14 days and is now flagged as stale. If this issue is still affecting you and in need of further review, please comment on it with an update to keep it from auto closing in 7 days.
The same issue, unable to start new version
Is there a verification process for these issues or is just merging in the fix good enough?
Generally, (sometimes automatically) the issues are closed when the PR is merged to main. I'll close this issue based on the PR landing.