tersec

 why does it modify all these submodule commits?

Obsoleted by other PRs.

https://github.com/status-im/nimbus-eth2/blob/667c3c97ebe3c40fd724cf80c991410e1cd32900/beacon_chain/spec/engine_authentication.nim#L87-L103 contains this functionality. It works in my testing. It selects the first line, i.e. up to the line break, but does not include it, which I believe is what...

instrumentation: ```nim diff --git a/beacon_chain/spec/engine_authentication.nim b/beacon_chain/spec/engine_authentication.nim index 5e7720d4..ca940986 100644 --- a/beacon_chain/spec/engine_authentication.nim +++ b/beacon_chain/spec/engine_authentication.nim @@ -90,8 +90,11 @@ proc checkJwtSecret*( if lines.len > 0: # Secret JWT key is parsed in...

https://github.com/status-im/nim-json-rpc/commit/7c80b758566950950ab5e3b29fe7f38c3b8168b0 might have already resolved this, based on the logs you show. It replaces ```nim raise (ref RpcPostError)(msg: "Failed to send POST Request with JSON-RPC.", parent: e) ``` with ```nim...

It seems to just take the response directly, unparsed, yeah.

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....

> 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...

In general, are "execution layer" and "execution client" treated as proper nouns by the spec? I agree with using that rather than engine API, but I'm not sure about the...