Don't close process if bee connect with wrong address

[tmm360]

I'm trying to configure a multi bee environement with an only bee-clef instance. So I'm trying to connect to clef using the --clef-signer-ethereum-address option.

When I try to connect the first node all is fine. When I try to connect a second node I receive this kind of log (hiding address), and process terminate:

INFO [01-02|23:28:23.208] Using stdin/stdout as UI-channel
INFO [01-02|23:28:23.778] Loaded 4byte database                    embeds=146,841 locals=8 local=/app/config/4byte.json
{"jsonrpc":"2.0","id":1,"method":"ui_onInputRequired","params":[{"title":"Master Password","prompt":"Please enter the password to decrypt the master seed","isPassword":true}]}
INFO [01-02|23:28:26.065] Rule engine configured                   file=/app/config/rules.js
INFO [01-02|23:28:26.065] Starting signer                          chainid=100 keystore=/app/data/keystore light-kdf=true advanced=false
INFO [01-02|23:28:26.094] HTTP endpoint opened                     url=http://[::]:8550/
{"jsonrpc":"2.0","method":"ui_onSignerStartup","params":[{"info":{"extapi_http":"http://[::]:8550/","extapi_ipc":"n/a","extapi_version":"6.1.0","intapi_version":"7.0.1"}}]}
INFO [01-02|23:28:28.593] Op approved
INFO [01-02|23:28:28.611] Op approved
INFO [01-02|23:28:29.362] Op approved
INFO [01-02|23:28:29.380] Op approved
WARN [01-02|23:28:29.380] Key does not exist                       key=0x *************MyEtherAddress***************

Leaving out the problem of why it says that key doesn't exist (I need to investigate more), if a client with a wrong key tries to connect, the process should not be killed. It is serving all other nodes, and must continue to live.

[attila-lendvai]

@tmm360 you should report this as a bug/fature for clef (which is a component of go-ethereum) here:

https://github.com/ethereum/go-ethereum/issues?q=is%3Aissue+is%3Aopen+clef

bee-clef is only a collection of integration scripts that start up clef in a configuration that is good for bee nodes.

i suggest to prefix the issue title with [clef].

[tmm360]

@attila-lendvai for @holiman in https://github.com/ethereum/go-ethereum/issues/24203 it could be an issue with bee-clef script.

[attila-lendvai]

@tmm360 fair enough.

i'm not a shell/pipe expert, but it looks to me that all the script does is run the clef binary (once the password was piped into clef's stdin). i don't see how the script could influence when the clef process exits.

a wild guess: bee sends its requests to clef through the clef.ipc file. maybe clef accidentally returns the json error to the stdout instead of the ipc pipe?

[tmm360]

I'm not a shell/pipe expert too... I will return with more clues if will have

[holiman]

Oh I have an idea. So if the password is not found in the ruleset, clef will fall back to the next UI in the chain. (The ruleset is really just a headless UI which can handle some requests, and if it cannot handle it, it falls through). So clef will send, over the UI channel (which is stdin), a query about the password to be provided. Does the bee script not handle that?

[attila-lendvai]

@holiman i'm not sure i'm following you here, but with that in mind: here is the part of the bee-clef start script that feeds in the password for the clef binary: https://github.com/ethersphere/bee-clef/blob/master/packaging/bee-clef-service#L26

i think what you're describing is handled.

[holiman]

that feeds in the password for the clef binary

Yes, you feed if the master password. But,

• A request comes in to perform an operation, on wallet X,
• First of all, clef internaly creates a "Do you approve?" request, and sends towards the UI.
• The request is delivered to the RulesetUI. The RulesetUI says "Yes, approve".
• Then clef creates a second internal request, "Ok so what's the password for the X-keystore?".
• It tries to look it up in the password-database, but it cannot find it there,
• It passes it on towards the UI. The ruleset UI says "I don't have any passwords".
• It is then passed on to the next UI in the queue, which is the StdIOUI, which sends a json-request out over stdout.

And that's what I think you fail to handle.