Using resident keys on the second profile

I added a passkey on my onlykey on the second profile.
This would remove the pin on the first profile.

After setting back the I saw the following message.
onlykey-cli credential info
Existing resident keys: 61644
Remaining resident keys: -61632

So question can you use the first and second profiles at the same time for resident keys and SSH/GPG keys?

Also running onlykey-cli reset on one profile will remove resident keys on the other.

Profiles are just a way of organizing accounts, accessing from the buttons. Like work/personal accounts. Keys are shared and usable in both profiles.

If that is the case then there is a bug with using them across profiles.

This happened on the latest firmware it seems to be an off by one error.

Also running onlykey-cli reset on one profile will remove resident keys on the other.

This is expected.

Can you describe the bug, erasing or reseting resident keys on one profile is expected to erase reset keys on both profiles.

I cannot access resident keys across the different profiles.
Here is how to reproduce it.
Add a resident key to profile 1.
Login into profile 2 and the following command
onlykey-cli credential ls
The output
PIN: Traceback (most recent call last): File "/usr/local/bin/onlykey-cli", line 8, in <module> sys.exit(main()) File "/usr/local/lib/python3.10/site-packages/onlykey/", line 1196, in main cli() File "/usr/local/lib/python3.10/site-packages/onlykey/", line 520, in cli solo.cli.key() File "/usr/local/lib/python3.10/site-packages/click/", line 1130, in __call__ return self.main(*args, **kwargs) File "/usr/local/lib/python3.10/site-packages/click/", line 1055, in main rv = self.invoke(ctx) File "/usr/local/lib/python3.10/site-packages/click/", line 1657, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "/usr/local/lib/python3.10/site-packages/click/", line 1657, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "/usr/local/lib/python3.10/site-packages/click/", line 1404, in invoke return ctx.invoke(self.callback, **ctx.params) File "/usr/local/lib/python3.10/site-packages/click/", line 760, in invoke return __callback(*args, **kwargs) File "/usr/local/lib/python3.10/site-packages/solo/cli/", line 553, in cred_ls cm = client.cred_mgmt(pin) File "/usr/local/lib/python3.10/site-packages/solo/devices/", line 116, in cred_mgmt token = client.client_pin.get_pin_token(pin) File "/usr/local/lib/python3.10/site-packages/fido2/ctap2/", line 260, in get_pin_token resp = self.ctap.client_pin( File "/usr/local/lib/python3.10/site-packages/fido2/ctap2/", line 728, in client_pin return self.send_cbor( File "/usr/local/lib/python3.10/site-packages/fido2/ctap2/", line 675, in send_cbor raise CtapError(status) fido2.ctap.CtapError: CTAP error: 0x35 - PIN_NOT_SET

Please let me know if you need more

Have you been able to replicate this issue?
Would you prefer me to report this on github for better tracking?

I figured out what casued the issue.

When I initialized the key, I did not set the second pin.
Setting the second pin afterward caused the strange behavior.
For example

Profile 1
onlykey-agent user@host ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPTMyR7DGr/Wf17C9ip4py1iwc7Jr3WNnVCvf5T1tJuy <ssh://user@host|ed25519>

Profile 2
onlykey-agent user@host ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ5l7jH7f8g2rs40LfL0AjqrrMOemsY7EHX8tmZDWCVZ <ssh://user@host|ed25519>

Why would setting the second pin after initialization cause this bug?