-
Couldn't load subscription status.
- Fork 21.5k
all: remove personal RPC namespace
#30704
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| } | ||
|
|
||
| if ctx.IsSet(EnablePersonal.Name) { | ||
| cfg.EnablePersonal = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we exit geth here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or at least print a warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Warning sgtm!
personal namespacepersonal RPC namespace
This PR is a first step towards removing account management from geth, and contains a lot of the user-facing changes. With this PR, the `personal` namespace disappears. **Note**: `personal` namespace has been deprecated for quite some time (since ethereum#26390 1 year and 8 months ago), and users who have wanted to use it has been forced to used the flag `--rpc.enabledeprecatedpersonal`. So I think it's fairly non-controversial to drop it at this point. Specifically, this means: - Account/wallet listing -`personal.getListAccounts` -`personal.listAccounts` -`personal.getListWallets` -`personal.listWallets` - Lock/unlock -`personal.lockAccount` -`personal.openWallet` -`personal.unlockAccount` - Sign ops -`personal.sign` -`personal.sendTransaction` -`personal.signTransaction` - Imports / inits -`personal.deriveAccount` -`personal.importRawKey` -`personal.initializeWallet` -`personal.newAccount` -`personal.unpair` - Other: -`personal.ecRecover` The underlying keystores and account managent code is still in place, which means that `geth --dev` still works as expected, so that e.g. the example below still works: ``` > eth.sendTransaction({data:"0x6060", value: 1, from:eth.accounts[0]}) ``` Also, `ethkey` and `clef` are untouched. With the removal of `personal`, as far as I know we have no more API methods which contain credentials, and if we want to implement logging-capabilities of RPC ingress payload, it would be possible after this. --------- Co-authored-by: Felix Lange <[email protected]>
This PR is a first step towards removing account management from geth, and contains a lot of the user-facing changes. With this PR, the `personal` namespace disappears. **Note**: `personal` namespace has been deprecated for quite some time (since #26390 1 year and 8 months ago), and users who have wanted to use it has been forced to used the flag `--rpc.enabledeprecatedpersonal`. So I think it's fairly non-controversial to drop it at this point. Specifically, this means: - Account/wallet listing -`personal.getListAccounts` -`personal.listAccounts` -`personal.getListWallets` -`personal.listWallets` - Lock/unlock -`personal.lockAccount` -`personal.openWallet` -`personal.unlockAccount` - Sign ops -`personal.sign` -`personal.sendTransaction` -`personal.signTransaction` - Imports / inits -`personal.deriveAccount` -`personal.importRawKey` -`personal.initializeWallet` -`personal.newAccount` -`personal.unpair` - Other: -`personal.ecRecover` The underlying keystores and account managent code is still in place, which means that `geth --dev` still works as expected, so that e.g. the example below still works: ``` > eth.sendTransaction({data:"0x6060", value: 1, from:eth.accounts[0]}) ``` Also, `ethkey` and `clef` are untouched. With the removal of `personal`, as far as I know we have no more API methods which contain credentials, and if we want to implement logging-capabilities of RPC ingress payload, it would be possible after this. --------- Co-authored-by: Felix Lange <[email protected]>
This PR is a first step towards removing account management from geth, and contains a lot of the user-facing changes. With this PR, the `personal` namespace disappears. **Note**: `personal` namespace has been deprecated for quite some time (since ethereum#26390 1 year and 8 months ago), and users who have wanted to use it has been forced to used the flag `--rpc.enabledeprecatedpersonal`. So I think it's fairly non-controversial to drop it at this point. Specifically, this means: - Account/wallet listing -`personal.getListAccounts` -`personal.listAccounts` -`personal.getListWallets` -`personal.listWallets` - Lock/unlock -`personal.lockAccount` -`personal.openWallet` -`personal.unlockAccount` - Sign ops -`personal.sign` -`personal.sendTransaction` -`personal.signTransaction` - Imports / inits -`personal.deriveAccount` -`personal.importRawKey` -`personal.initializeWallet` -`personal.newAccount` -`personal.unpair` - Other: -`personal.ecRecover` The underlying keystores and account managent code is still in place, which means that `geth --dev` still works as expected, so that e.g. the example below still works: ``` > eth.sendTransaction({data:"0x6060", value: 1, from:eth.accounts[0]}) ``` Also, `ethkey` and `clef` are untouched. With the removal of `personal`, as far as I know we have no more API methods which contain credentials, and if we want to implement logging-capabilities of RPC ingress payload, it would be possible after this. --------- Co-authored-by: Felix Lange <[email protected]>
This PR is a first step towards removing account management from geth, and contains a lot of the user-facing changes. With this PR, the `personal` namespace disappears. **Note**: `personal` namespace has been deprecated for quite some time (since ethereum#26390 1 year and 8 months ago), and users who have wanted to use it has been forced to used the flag `--rpc.enabledeprecatedpersonal`. So I think it's fairly non-controversial to drop it at this point. Specifically, this means: - Account/wallet listing -`personal.getListAccounts` -`personal.listAccounts` -`personal.getListWallets` -`personal.listWallets` - Lock/unlock -`personal.lockAccount` -`personal.openWallet` -`personal.unlockAccount` - Sign ops -`personal.sign` -`personal.sendTransaction` -`personal.signTransaction` - Imports / inits -`personal.deriveAccount` -`personal.importRawKey` -`personal.initializeWallet` -`personal.newAccount` -`personal.unpair` - Other: -`personal.ecRecover` The underlying keystores and account managent code is still in place, which means that `geth --dev` still works as expected, so that e.g. the example below still works: ``` > eth.sendTransaction({data:"0x6060", value: 1, from:eth.accounts[0]}) ``` Also, `ethkey` and `clef` are untouched. With the removal of `personal`, as far as I know we have no more API methods which contain credentials, and if we want to implement logging-capabilities of RPC ingress payload, it would be possible after this. --------- Co-authored-by: Felix Lange <[email protected]>
This PR is a first step towards removing account management from geth, and contains a lot of the user-facing changes.
With this PR, the
personalnamespace disappears. Note:personalnamespace has been deprecated for quite some time (since #26390 1 year and 8 months ago), and users who have wanted to use it has been forced to used the flag--rpc.enabledeprecatedpersonal. So I think it's fairly non-controversial to drop it at this point.Specifically, this means:
-
personal.getListAccounts-
personal.listAccounts-
personal.getListWallets-
personal.listWallets-
personal.lockAccount-
personal.openWallet-
personal.unlockAccount-
personal.sign-
personal.sendTransaction-
personal.signTransaction-
personal.deriveAccount-
personal.importRawKey-
personal.initializeWallet-
personal.newAccount-
personal.unpair-
personal.ecRecoverThe underlying keystores and account managent code is still in place, which means that
geth --devstill works as expected, so that e.g. the example below still works:Also,
ethkeyandclefare untouched.With the removal of
personal, as far as I know we have no more API methods which contain credentials, and if we want to implement logging-capabilities of RPC ingress payload, it would be possible after this.