There's an obscure situation we've fixed recently that really should have test cases.
1) Create an account.
2) Push a PGP key using the website that does not include the account ID.
This puts the user in a situation where their public key is asserted by unproven. Actions taken by that user, like tracking, should still work (and in fact will count as proving ownership of the key). But while the user is in this state, other users should see failures from e.g. keybase id.
Another:
1) Create an account with an eldest key and some signed links.
2) keybase revoke to reset your account.
This leaves you with no public key but a non-empty sigchain. Previously we weren't nulling out your eldest key in the Merkle tree, which had bad consequences. (Your client would think you still had a key, and would refuse to upload a new one.) We can also use this state as an alternative setup for the first test above.
Both of these require implementing website-key-push in the node-client testing framework, which is some work.
There's an obscure situation we've fixed recently that really should have test cases.
1) Create an account. 2) Push a PGP key using the website that does not include the account ID.
This puts the user in a situation where their public key is asserted by unproven. Actions taken by that user, like tracking, should still work (and in fact will count as proving ownership of the key). But while the user is in this state, other users should see failures from e.g.
keybase id.Another:
1) Create an account with an eldest key and some signed links. 2)
keybase revoketo reset your account.This leaves you with no public key but a non-empty sigchain. Previously we weren't nulling out your eldest key in the Merkle tree, which had bad consequences. (Your client would think you still had a key, and would refuse to upload a new one.) We can also use this state as an alternative setup for the first test above.
Both of these require implementing website-key-push in the node-client testing framework, which is some work.