nimbus-eth2
nimbus-eth2 copied to clipboard
status-im
re-read jwt secret on every connection attempt
The JWT secret file is created by the EL when it starts - because of ordering differences between EL and CL startups, we should read the JWT secret file when making the connection attempt - this also addresses the case where the JWT secret changes (for example because the EL restarts and writes a new secret, for whatever reason).
If the JWT secret cannot be read, it is equivalent to an authentication failure and should be treated as such for the purpose of error handling / recovery.
This has the potential to create new failure modes, too -- for "whatever reason", the local JWT secret file Nimbus had used becomes unreadable, but it's not in fact changed. This undermines much of the intent initial checks on startup in favor of supporting a more dynamic configuration which is intrinsically not as statically-verifiable and might cause random failures at random points through a run.
Perhaps a re-read should be attempted upon a connection failure (as defined by the awaitWithRetries logic which gives up only after multiple failed requests).
Or we can handle a response that specifically indicates that the JWT value is rejected.
this happens when you have jwt stored on /tmp then restart the machine with geth (because geth will create a new one) - we can attempt a read and use the "latest-known-good" if the read fails - we should also not really be making verifications on startup: the order in which el and cl start is random and it's the responsibility of the EL to create a secret
it's the responsibility of the EL to create a secret
That's not unambiguous: https://github.com/ethereum/execution-apis/pull/289
This interpretive ambiguity renders the idea of relying on auto-generated JWT secrets by either CL or EL clients problematic. This is why in my own communication on the topic, I've suggested avoiding this.