rpc: actually deprecate rpcuser & rpcpass #29240

1. 
   fanquake commented at 10:53 am on January 12, 2024: member

   The logging to output that Config options rpcuser and rpcpassword will soon be deprecated. was added ~8 years ago in #7044. However these options still continue to get new usage today, i.e https://github.com/lightningnetwork/lnd/pull/8354#discussion_r1450166947, and it’s easy to forget they are considered deprecated, given they aren’t under the normal deprecation mechanism/there aren’t more verbose warnings.

   If we are going to deprecate these options, now seems like a good time to do so. We could start with updating all examples / docs in this repository, to remove any rpcuser/rpcpass usage.

   If we aren’t actually planning on ever deprecating/removing these options, we should probably update the logging output to remove the mentions of future deprecation.

2. fanquake added the label Docs on Jan 12, 2024
3. fanquake added the label RPC/REST/ZMQ on Jan 12, 2024
4. 
   kristapsk commented at 8:07 pm on January 12, 2024: contributor

   If we are going to deprecate these options, now seems like a good time to do so. We could start with updating all exmaples / docs in this repository, to remove any rpcuser/rpcpass usage.

   That should definitely be done first.

   One thing with cookie auth, that currently needs hacks, is allowing cookie access for other users. #28167

5. 
   willcl-ark commented at 10:21 am on January 16, 2024: member

   Surprisingly I found very few instances of rpcuser and rpcpassword remaining in the docs. I updated their usage, and the example init scripts, in this branch to see the scope of changes that would be required on the doc side.

   I think if we want to fully deprecate these options, the changes in that branch along with #28167 as mentioned above, should come first.

   My opinion is that it would be best to still try and fully deprecate these, but due to how widely they are used we will have to include some highly visible warnings about the new behaviour… Some thoughts I had on this:

   • We would need to decide if having these keys in bitcoin.conf would halt bitcoind/-qt startup
     • If we don’t fail startup (just log a warning to debug.log and ignore the options) users would wonder why their RPC calls are “mysteriously” failing when their credentials match those in bitcoin.conf. Presumably Bitcoin Core would silently be using a .cookie in this case.
     • If we do fail startup then it’s possible that many (semi) automated node setups would simply fail to start back up after an upgrade – without manual intervention to remove these keys from the config – which seems pretty sub-optimal.
   • Asking users who have always been able to just run the binaries + a config file, to now run a python script from share/ to generate auth credentials feels a bit, messy?
     • Perhaps bitcoin-cli should get a generaterpcauth command?

   An alternative might be to not deprecate these options at all, but instead we could require specific permissions on the bitcoin.conf file itself, like how ssh requires specific permissions of 600 for id_rsa private key files. I don’t like this idea much as it is not providing the same level of security as the rpcauth directive, and AFAIU doesn’t bring benefit to Windows users in the same way. But it is quite similar in protection mechanism to the cookie file (i.e. read access to the (config) file grants you RPC access). Notably this does not solve the same fail-to-restart-after-upgrade issues mentioned above. The config file permissions option doesn’t seem to me to offer enough reward:risk.

6. 
   pythcoiner commented at 1:25 pm on May 26, 2024: none

   Asking users who have always been able to just run the binaries + a config file, to now run a python script from share/ to generate auth credentials feels a bit, messy?

   • Perhaps bitcoin-cli should get a generaterpcauth command?

   good point, especially for windows users that get the binaries from bitcoin.org, they get only the .exe, i don’t know if they have access to /share after installation? Maybe a feature in bitcoin-qt is also needed?

Contributors
fanquake kristapsk willcl-ark pythcoiner

Labels
Docs RPC/REST/ZMQ