mirror of
https://github.com/ethereum/go-ethereum.git
synced 2026-08-20 02:42:27 +00:00
clef: updates to doc
This commit is contained in:
parent
62226fd5dc
commit
2e340319d4
3 changed files with 19 additions and 21 deletions
|
|
@ -31,8 +31,8 @@ COMMANDS:
|
||||||
|
|
||||||
GLOBAL OPTIONS:
|
GLOBAL OPTIONS:
|
||||||
--loglevel value log level to emit to the screen (default: 4)
|
--loglevel value log level to emit to the screen (default: 4)
|
||||||
--keystore value Directory for the keystore (default: "/home/user/.ethereum/keystore")
|
--keystore value Directory for the keystore (default: "$HOME/.ethereum/keystore")
|
||||||
--configdir value Directory for Clef configuration (default: "/home/user/.clef")
|
--configdir value Directory for Clef configuration (default: "$HOME/.clef")
|
||||||
--chainid value Chain id to use for signing (1=mainnet, 3=ropsten, 4=rinkeby, 5=Goerli) (default: 1)
|
--chainid value Chain id to use for signing (1=mainnet, 3=ropsten, 4=rinkeby, 5=Goerli) (default: 1)
|
||||||
--lightkdf Reduce key-derivation RAM & CPU usage at some expense of KDF strength
|
--lightkdf Reduce key-derivation RAM & CPU usage at some expense of KDF strength
|
||||||
--nousb Disables monitoring for and managing USB hardware wallets
|
--nousb Disables monitoring for and managing USB hardware wallets
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,6 @@
|
||||||
## UI Client interface
|
## UI Client interface
|
||||||
|
|
||||||
These data types are defined in the channel between clef and the UI
|
These data types are defined in the channel between clef and the UI
|
||||||
|
|
||||||
### SignDataRequest
|
### SignDataRequest
|
||||||
|
|
||||||
SignDataRequest contains information about a pending request to sign some data. The data to be signed can be of various types, defined by content-type. Clef has done most of the work in canonicalizing and making sense of the data, and it's up to the UI to presentthe user with the contents of the `message`
|
SignDataRequest contains information about a pending request to sign some data. The data to be signed can be of various types, defined by content-type. Clef has done most of the work in canonicalizing and making sense of the data, and it's up to the UI to presentthe user with the contents of the `message`
|
||||||
|
|
@ -31,7 +30,7 @@ Example:
|
||||||
```
|
```
|
||||||
### SignDataResponse - approve
|
### SignDataResponse - approve
|
||||||
|
|
||||||
Reponse to SignDataRequest
|
Response to SignDataRequest
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
```json
|
```json
|
||||||
|
|
@ -42,7 +41,7 @@ Example:
|
||||||
```
|
```
|
||||||
### SignDataResponse - deny
|
### SignDataResponse - deny
|
||||||
|
|
||||||
Reponse to SignDataRequest
|
Response to SignDataRequest
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
```json
|
```json
|
||||||
|
|
@ -53,7 +52,7 @@ Example:
|
||||||
```
|
```
|
||||||
### SignTxRequest
|
### SignTxRequest
|
||||||
|
|
||||||
SignTxRequest contains information about a pending request to sign a transaction.Aside from the transaction itself, there is also a call_info-struct. That struct containsmessages of various types, that the user should be informed of.
|
SignTxRequest contains information about a pending request to sign a transaction. Aside from the transaction itself, there is also a `call_info`-struct. That struct contains messages of various types, that the user should be informed of.
|
||||||
|
|
||||||
As in any request, it's important to consider that the `meta` info also contains untrusted data.
|
As in any request, it's important to consider that the `meta` info also contains untrusted data.
|
||||||
|
|
||||||
|
|
@ -92,7 +91,7 @@ Example:
|
||||||
```
|
```
|
||||||
### SignDataResponse - approve
|
### SignDataResponse - approve
|
||||||
|
|
||||||
Reponse to SignDataRequest. This response needs to contain the `transaction`, because the UI is free to make modifications to the transaction.
|
Response to SignDataRequest. This response needs to contain the `transaction`, because the UI is free to make modifications to the transaction.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
```json
|
```json
|
||||||
|
|
@ -112,7 +111,7 @@ Example:
|
||||||
```
|
```
|
||||||
### SignDataResponse - deny
|
### SignDataResponse - deny
|
||||||
|
|
||||||
Reponse to SignDataRequest. When denying a request, there's no need to provide the transaction in return
|
Response to SignDataRequest. When denying a request, there's no need to provide the transaction in return
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
```json
|
```json
|
||||||
|
|
@ -125,11 +124,11 @@ Example:
|
||||||
|
|
||||||
SignTransactionResult is used in the call `clef` -> `OnApprovedTx(result)`
|
SignTransactionResult is used in the call `clef` -> `OnApprovedTx(result)`
|
||||||
|
|
||||||
This occurs _after_ successfull completion of the entire signing procedure, but right before the signed transaction is passed to the external caller. This method (and data) can be used by the UI to signal to the user that the transaction was signed, but it is primarily useful for ruleset implementations.
|
This occurs _after_ successful completion of the entire signing procedure, but right before the signed transaction is passed to the external caller. This method (and data) can be used by the UI to signal to the user that the transaction was signed, but it is primarily useful for ruleset implementations.
|
||||||
|
|
||||||
A ruleset that implements a rate limitation needs to know what transactions are sent out to the external interface. By hooking into this methods, the ruleset can maintain track of that count.
|
A ruleset that implements a rate limitation needs to know what transactions are sent out to the external interface. By hooking into this methods, the ruleset can maintain track of that count.
|
||||||
|
|
||||||
**OBS:** Note that if an attacker can restore your `clef` data to a previous point in time (e.g through a backup), he can reset such windows, even if he is unable to decrypt the content.
|
**OBS:** Note that if an attacker can restore your `clef` data to a previous point in time (e.g through a backup), the attacker can reset such windows, even if he/she is unable to decrypt the content.
|
||||||
|
|
||||||
The `OnApproved` method cannot be responded to, it's purely informative
|
The `OnApproved` method cannot be responded to, it's purely informative
|
||||||
|
|
||||||
|
|
@ -165,7 +164,7 @@ Example:
|
||||||
```
|
```
|
||||||
### UserInputResponse
|
### UserInputResponse
|
||||||
|
|
||||||
Reponse to SignDataRequest
|
Response to SignDataRequest
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
```json
|
```json
|
||||||
|
|
@ -201,7 +200,7 @@ Example:
|
||||||
```
|
```
|
||||||
### UserInputResponse
|
### UserInputResponse
|
||||||
|
|
||||||
Reponse to list request. The response contains a list of all addresses to show the caller. Note: the UI is free to respond with any address the caller, regardless of whether it exists or not
|
Response to list request. The response contains a list of all addresses to show to the caller. Note: the UI is free to respond with any address the caller, regardless of whether it exists or not
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
```json
|
```json
|
||||||
|
|
|
||||||
|
|
@ -799,7 +799,7 @@ func GenDoc(ctx *cli.Context) {
|
||||||
}
|
}
|
||||||
{ // Sign transaction request
|
{ // Sign transaction request
|
||||||
desc := "SignTxRequest contains information about a pending request to sign a transaction. " +
|
desc := "SignTxRequest contains information about a pending request to sign a transaction. " +
|
||||||
"Aside from the transaction itself, there is also a call_info-struct. That struct contains" +
|
"Aside from the transaction itself, there is also a `call_info`-struct. That struct contains " +
|
||||||
"messages of various types, that the user should be informed of." +
|
"messages of various types, that the user should be informed of." +
|
||||||
"\n\n" +
|
"\n\n" +
|
||||||
"As in any request, it's important to consider that the `meta` info also contains untrusted data." +
|
"As in any request, it's important to consider that the `meta` info also contains untrusted data." +
|
||||||
|
|
@ -856,7 +856,7 @@ func GenDoc(ctx *cli.Context) {
|
||||||
"interface. By hooking into this methods, the ruleset can maintain track of that count." +
|
"interface. By hooking into this methods, the ruleset can maintain track of that count." +
|
||||||
"\n\n" +
|
"\n\n" +
|
||||||
"**OBS:** Note that if an attacker can restore your `clef` data to a previous point in time" +
|
"**OBS:** Note that if an attacker can restore your `clef` data to a previous point in time" +
|
||||||
" (e.g through a backup), he can reset such windows, even if he is unable to decrypt the content. " +
|
" (e.g through a backup), the attacker can reset such windows, even if he/she is unable to decrypt the content. " +
|
||||||
"\n\n" +
|
"\n\n" +
|
||||||
"The `OnApproved` method cannot be responded to, it's purely informative"
|
"The `OnApproved` method cannot be responded to, it's purely informative"
|
||||||
|
|
||||||
|
|
@ -883,7 +883,7 @@ func GenDoc(ctx *cli.Context) {
|
||||||
{b, accounts.URL{Scheme: "keystore", Path: "/path/to/keyfile/b"}}},
|
{b, accounts.URL{Scheme: "keystore", Path: "/path/to/keyfile/b"}}},
|
||||||
})
|
})
|
||||||
|
|
||||||
add("UserInputResponse", "Response to list request. The response contains a list of all addresses to show the caller. "+
|
add("UserInputResponse", "Response to list request. The response contains a list of all addresses to show to the caller. "+
|
||||||
"Note: the UI is free to respond with any address the caller, regardless of whether it exists or not",
|
"Note: the UI is free to respond with any address the caller, regardless of whether it exists or not",
|
||||||
&core.ListResponse{
|
&core.ListResponse{
|
||||||
Accounts: []accounts.Account{
|
Accounts: []accounts.Account{
|
||||||
|
|
@ -894,8 +894,7 @@ func GenDoc(ctx *cli.Context) {
|
||||||
|
|
||||||
fmt.Println(`## UI Client interface
|
fmt.Println(`## UI Client interface
|
||||||
|
|
||||||
These data types are defined in the channel between clef and the UI
|
These data types are defined in the channel between clef and the UI`)
|
||||||
`)
|
|
||||||
for _, elem := range output {
|
for _, elem := range output {
|
||||||
fmt.Println(elem)
|
fmt.Println(elem)
|
||||||
}
|
}
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue