Support specifying rpcpassword by file #10071

Original issue: https://github.com/namecoin/namecoin-core/issues/148.

Currently the rpcpassword must be specified in the configuration file. On some systems (for example in NixOS) configuration files are stored in world-readable locations. It's a bad idea to store secrets in world-readable locations.

To better support these systems it would be nice if there was a rpcpasswordFile configuration parameter. Users can then keep the configuration file in a world-readable location but set rpcpasswordFile to a file with restricted ownership and permissions.

Another (more general) approach, also used in many other daemons, would be to support include statements in configuration files, this would allow including any options from other places besides the main configuration file not just the password.

BTW rpcpassword is deprecated. If you use the newer rpcauth mechanism (introduced in #7044, first in 0.12.0) you can use hashed passwords in the configuration file. This is not a workaround for storing secrets in world-readable locations but makes it non-trivial to recover the cleartext password given access to the configuration file.

Sorry for the spam. Every time I rebase that commit it pings this thread. Wish Github was more intelligent in that regard.

@kallewoof - reword the commit message to remove the issue #.

Arguably, commit messages shouldn't contain references to issues, which are a github concept - the git repository should stand alone.

Arguably, commit messages shouldn't contain references to issues, which are a github concept - the git repository should stand alone.

In a purely ontological sense you are right, but in practice I disagree: I really like to see issue IDs while looking back (though leaving out the # is of course fine) because they allow me to look up the context of something and the discussion around it.

Sorry for the spam. Every time I rebase that commit it pings this thread. Wish Github was more intelligent in that regard.

Yes would be useful if it garbage-collected notifications from no-longer-referenced commits.

In a purely ontological sense you are right, but in practice I disagree: I really like to see issue IDs while looking back (though leaving out the # is of course fine) because they allow me to look up the context of something and the discussion around it.

If I'm not mistaken, referencing an issue in a commit as "fixes <issue#>" will actually auto-close the issue when the PR is merged. That's also handy, I guess.

@kallewoof note that you can include it in the PR OP and not in the commit message and it will work fine without this spam ^ :)