Do not ask a human about a ping - #49
Merged
Merged
Conversation
Every request the allowlist permitted went to the approval queue, which parks the calling thread until somebody answers or two minutes pass. That caller is the relay serve loop, so one unanswered request stops the signer answering anything at all. Most of what arrives does not touch the key. `connect` and `logout` move a client in and out of the authorized set, `ping` is liveness, and `get_public_key` returns a value already printed in the `bunker://` token the user hands out. None of them is a decision a person can usefully make, and each one sitting in the queue is a prompt that teaches people to click approve without reading. It was also a way to switch the signer off. `ping` and `get_public_key` are answered for clients that have NOT connected, deliberately, so a stranger who knew the bunker pubkey could send one ping every two minutes and keep the signer permanently busy without ever presenting the secret. Requiring a connect first does not help here, because these two are exactly the methods that do not require it. Only `sign_event`, `nip44_encrypt` and `nip44_decrypt` reach a person now. An unrecognised method still does: the bunker rejects it afterwards, but a name this does not know is not something to wave through. The new test asserts the absence of a prompt by asserting speed. The broker is given a short timeout and nothing resolves it, so anything that escalated would come back denied; returning approve at once is the proof it never went to the queue.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every request the allowlist permitted went to the approval queue, and
submitparks the calling thread until somebody answers or two minutes pass. That caller is the relay serve loop, so one unanswered request stops the signer answering anything at all.Most of what arrives does not touch the key.
connectandlogoutmove a client in and out of the authorized set,pingis liveness, andget_public_keyreturns a value already printed in thebunker://token the user hands out. None of them is a decision a person can usefully make, and each one sitting in the queue is a prompt that teaches people to click approve without reading.It was also a way to switch the signer off.
pingandget_public_keyare answered for clients that have not connected, deliberately, so a stranger who knew the bunker pubkey could send onepingevery two minutes and keep the signer permanently busy without ever presenting the connect secret. Requiring a connect first does not help here, because these two are exactly the methods that do not require it.Only
sign_event,nip44_encryptandnip44_decryptreach a person now. An unrecognised method still does: the bunker rejects it afterwards, but a name this does not know is not something to wave through here.On the test
It asserts the absence of a prompt by asserting speed. The broker gets a short timeout and nothing resolves it, so anything that escalated would block and come back denied; returning
approveimmediately is the proof it never reached the queue. Checked against the bug: with the guard removed, that test fails and the rest still pass.