Adjusts wording and removes disk writing requirement. #298
Conversation
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
We should try to avoid using acronyms in specifications as it makes it harder for new participants in the ecosystem to process, so I have changed all references to EL and CL to execution layer and consensus layer. Also, in many cases in this document the term EL was used when EL client was meant, so I appended "client" as appropriate. While writing to the filesystem is useful in some setups, in others it may be a security risk. For this reason, the **MUST** write to disk was changed to a **SHOULD** write to disk so that a client that doesn't write the token to disk isn't out of compliance.
lightclient
approved these changes
Aug 26, 2022
MicahZoltu
pushed a commit
to MicahZoltu/eth1.0-apis
that referenced
this pull request
Aug 26, 2022
This spec, as currently written is incredibly prescriptive about exactly how the key should be provided to the client. This doesn't allow clients to differentiate in ways that are useful to their customers without falling out of spec compliance. One can easily imagine a user wanting to configure this via environment variable, or CLI parameter rather than via file. Also, files on disk may not be secure against reading by unauthorized users (for example, disk backups may not be encrypted) while access to startup parameters and environment variables may be better protected. A client may also integrate with a secure secret storage system that allows the client to fetch secrets from a server over a secure connection at startup, thus protecting the key from anyone who doesn't have the ability to read the contents of RAM while the client is running. Note, this change should be merged after ethereum#298 as it incorporates some of the wording changes found there. I can appreciate the value in having consistency in configuration parameter naming, I don't think we should be setting such things as required. Nethermind, for example, namespaces its configuration variables and having this be un-namespaced is likely to cause more confusion for users and more complexity in their client.
mkalinin
approved these changes
Sep 7, 2022
djrtwo
approved these changes
Sep 8, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
We should try to avoid using acronyms in specifications as it makes it harder for new participants in the ecosystem to process, so I have changed all references to EL and CL to execution layer and consensus layer. Also, in many cases in this document the term EL was used when EL client was meant, so I appended "client" as appropriate.
While writing to the filesystem is useful in some setups, in others it may be a security risk. For this reason, the MUST write to disk was changed to a SHOULD write to disk so that a client that doesn't write the token to disk isn't out of compliance.