RPC: Added additional config option for multiple RPC users. #7044

Merged
merged 1 commit into from Nov 30, 2015

Conversation

Projects
None yet
@instagibbs
Member

instagibbs commented Nov 17, 2015

This pull adds an additional config option, "rpcauth" to allow multiple different users to use different credentials for login.

Motivation:
In business settings there are often multiple users accessing a particular core instance, using wallet functionality. Instead of all users sharing the same login name and password, it is desired to have each user generate their own secret password, and have a hashed and salted version added to bitcoin.conf by the admin. Currently there is only one name and password, and it is stored in plaintext. This pull attempts to do just this and will be followed by an additional audit logging pull to enable admins to assign blame to spends and other irreversible actions.

The config option comes in the format:

rpcauth=USERNAME:SALT$HASH

Where:

  1. USERNAME is the desired username. Name does not have to be unique.
  2. SALT is the salt for the HMAC_SHA256 function
  3. HASH is a hex string that is the result of the HMAC_SHA256 function on the user's secret password plus the SALT as the key.

A "canonical" password generating python script has been supplied in share/rpcuser. From the client-side, one connects using the standard -rpcuser/-rpcpassword options.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Nov 17, 2015

Member

Please explain how your vision accounts for multi-wallet use. It seems desirable to have different users access different wallets (or perhaps even limited to specific accounts within a wallet), but your plan above does not seem to account for that possibility.

Member

luke-jr commented Nov 17, 2015

Please explain how your vision accounts for multi-wallet use. It seems desirable to have different users access different wallets (or perhaps even limited to specific accounts within a wallet), but your plan above does not seem to account for that possibility.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Nov 17, 2015

Member

@luke-jr That seems orthogonal to me. Presumably if we eventually wanted to layer access controls on top of this in the future (though we've shed away from that in the past), this appears completely compatible with doing so... but this is useful without that, just from an credential management perspective.

Member

gmaxwell commented Nov 17, 2015

@luke-jr That seems orthogonal to me. Presumably if we eventually wanted to layer access controls on top of this in the future (though we've shed away from that in the past), this appears completely compatible with doing so... but this is useful without that, just from an credential management perspective.

@sipa

View changes

src/httprpc.cpp
+ unsigned char *out = new unsigned char[KEY_SIZE];
+ char outhex[KEY_HEX_SIZE];
+
+ if (PKCS5_PBKDF2_HMAC(strPass.c_str(), strPass.size(),

This comment has been minimized.

@sipa

sipa Nov 17, 2015

Member

I think we really want to avoid adding OpenSSL dependencies. But it shouldn't be hard to add PBKDF2 (we already have a builtin HMAC-SHA256 implementation).

@sipa

sipa Nov 17, 2015

Member

I think we really want to avoid adding OpenSSL dependencies. But it shouldn't be hard to add PBKDF2 (we already have a builtin HMAC-SHA256 implementation).

This comment has been minimized.

@gmaxwell

gmaxwell Nov 17, 2015

Member

We're in that boat for the wallet encryption already.

@gmaxwell

gmaxwell Nov 17, 2015

Member

We're in that boat for the wallet encryption already.

This comment has been minimized.

@sipa

sipa Nov 17, 2015

Member

See #5949.

This comment has been minimized.

@jonasschnelli

jonasschnelli Nov 18, 2015

Member

This affects also --disable-wallet compilation (httprpc.cpp). Agree with @sipa. There is no reason to use openssl lump for that.

@jonasschnelli

jonasschnelli Nov 18, 2015

Member

This affects also --disable-wallet compilation (httprpc.cpp). Agree with @sipa. There is no reason to use openssl lump for that.

@sipa

View changes

src/httprpc.cpp
+ std::string strHashFromPass = std::string(outhex, KEY_HEX_SIZE);
+
+ if (TimingResistantEqual(strHashFromPass, strHash)) {
+ return true;

This comment has been minimized.

@sipa

sipa Nov 17, 2015

Member

Early return will break the timing resistance property. It's probably better to maintain a boleean return variable, and use |= to mix in the result.

@sipa

sipa Nov 17, 2015

Member

Early return will break the timing resistance property. It's probably better to maintain a boleean return variable, and use |= to mix in the result.

This comment has been minimized.

@instagibbs

instagibbs Nov 18, 2015

Member

Could you elaborate on what sort of timing info will leak? (unless you mean the function should try every single name/pass combination, and not call the continue on line 98 as well)

@instagibbs

instagibbs Nov 18, 2015

Member

Could you elaborate on what sort of timing info will leak? (unless you mean the function should try every single name/pass combination, and not call the continue on line 98 as well)

This comment has been minimized.

@sipa

sipa Nov 18, 2015

Member

Eh, it could leak which entry was matched... but I guess that's not considered very sensitive information.

I withdraw this comment :)

@sipa

sipa Nov 18, 2015

Member

Eh, it could leak which entry was matched... but I guess that's not considered very sensitive information.

I withdraw this comment :)

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Nov 18, 2015

Contributor

[weak] concept NACK, IMHO should be removing RPC complexity, not adding it.

edit: This could trivially be added externally, and would be less than 100-200 lines of code for a simply forwarding/authentication/logging HTTP server.

edit2: See after @gmaxwell's answer

Contributor

dcousens commented Nov 18, 2015

[weak] concept NACK, IMHO should be removing RPC complexity, not adding it.

edit: This could trivially be added externally, and would be less than 100-200 lines of code for a simply forwarding/authentication/logging HTTP server.

edit2: See after @gmaxwell's answer

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Nov 18, 2015

Member

@dcousens: that could be said of any functionality; thats really no excuse for having an auth setup which will be an immediate failure in any security audit. (And for context, I asked instagibbs to work on something like this after hearing from multiple parties that they switched from bitcoin core to an API provider for a list of reasons that included this; I'd like to get all of these reasons fixed.)

I don't see why you see this as increasing the complexity of RPC: it changes credential storage, not the RPC-- other than timing it's presence is externally indistinguishable.

I think we should phase out the old method of configuration and support only this and cookie auth; but thats incompatible so it should probably be phased in across multiple versions.

Member

gmaxwell commented Nov 18, 2015

@dcousens: that could be said of any functionality; thats really no excuse for having an auth setup which will be an immediate failure in any security audit. (And for context, I asked instagibbs to work on something like this after hearing from multiple parties that they switched from bitcoin core to an API provider for a list of reasons that included this; I'd like to get all of these reasons fixed.)

I don't see why you see this as increasing the complexity of RPC: it changes credential storage, not the RPC-- other than timing it's presence is externally indistinguishable.

I think we should phase out the old method of configuration and support only this and cookie auth; but thats incompatible so it should probably be phased in across multiple versions.

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Nov 18, 2015

Contributor

To clarify, the above was a weak NACK; and I may have jumped the gun on complexity, as after a code review, only ~20-30 lines was added code, the rest is tests.

If the alternative configuration method is [eventually] removed, then I see no issue with this and its an easy feature win for those who need it. Concept ACK, utACK

👍

Contributor

dcousens commented Nov 18, 2015

To clarify, the above was a weak NACK; and I may have jumped the gun on complexity, as after a code review, only ~20-30 lines was added code, the rest is tests.

If the alternative configuration method is [eventually] removed, then I see no issue with this and its an easy feature win for those who need it. Concept ACK, utACK

👍

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Nov 18, 2015

Member

Concept ACK.
I think keeping the credentials in bitcoin.conf (instead of a .passwd like file) is fine for a first step.

Nice work! Thanks for directly include a RPC test.

Member

jonasschnelli commented Nov 18, 2015

Concept ACK.
I think keeping the credentials in bitcoin.conf (instead of a .passwd like file) is fine for a first step.

Nice work! Thanks for directly include a RPC test.

@instagibbs

This comment has been minimized.

Show comment
Hide comment
@instagibbs

instagibbs Nov 18, 2015

Member

@paveljanik @jonasschnelli If we ever get around to deprecating the original rpc credential method I think that'd be a good time to move it.

Member

instagibbs commented Nov 18, 2015

@paveljanik @jonasschnelli If we ever get around to deprecating the original rpc credential method I think that'd be a good time to move it.

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Nov 18, 2015

Contributor

Is the salting and hashing really worth it? An admin could easily listen on the wire for the pre-stretched password. I feel like this is a false sense of security for what is meant to be a local (127.0.0.1) only interface?
While we're at it, why not just abandon the password?

The authentication itself is just basic HTTP authentication AFAIK. This is no better than just a single token. Clearer intent and security implications IMHO.

Contributor

dcousens commented Nov 18, 2015

Is the salting and hashing really worth it? An admin could easily listen on the wire for the pre-stretched password. I feel like this is a false sense of security for what is meant to be a local (127.0.0.1) only interface?
While we're at it, why not just abandon the password?

The authentication itself is just basic HTTP authentication AFAIK. This is no better than just a single token. Clearer intent and security implications IMHO.

@instagibbs

This comment has been minimized.

Show comment
Hide comment
@instagibbs

instagibbs Nov 18, 2015

Member

@dcousens salting and hashing protects the passwords in the case of an adversary getting a hold of the password file and forging irreversible requests immediately, but not an catching it across the wire, no. I still see value in that, especially for basic audit purposes.

Member

instagibbs commented Nov 18, 2015

@dcousens salting and hashing protects the passwords in the case of an adversary getting a hold of the password file and forging irreversible requests immediately, but not an catching it across the wire, no. I still see value in that, especially for basic audit purposes.

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Nov 18, 2015

Contributor

getting hold of the password file and forging irreversible requests immediately

I'd be willing to bet that the attacker will likely already be able to do this, be it through watching the wire or simply adding the auth settings to the bitcoin.conf.
It could be RO, but, in that case, why wouldn't it just be inaccessible.

If that sole property is desirable, then sure, add it. But it isn't reflective of the existing security model.

especially for basic audit purposes.

I'm not sure how user:password vs token relates to auditing?
It relates to printing user:action in the logs, whereas token would expose the secret too.
In this event, you could just use hash(token), but, I see the usability aspect of this.

Contributor

dcousens commented Nov 18, 2015

getting hold of the password file and forging irreversible requests immediately

I'd be willing to bet that the attacker will likely already be able to do this, be it through watching the wire or simply adding the auth settings to the bitcoin.conf.
It could be RO, but, in that case, why wouldn't it just be inaccessible.

If that sole property is desirable, then sure, add it. But it isn't reflective of the existing security model.

especially for basic audit purposes.

I'm not sure how user:password vs token relates to auditing?
It relates to printing user:action in the logs, whereas token would expose the secret too.
In this event, you could just use hash(token), but, I see the usability aspect of this.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Nov 18, 2015

Member

@dcousens: consider, a couple weeks ago I learned sipa's rpcpassword while he was showing me something in his bitcoin.conf on his screen.

Hashed passwords were the norm for system authentication decades before encrypted transports. :)

Member

gmaxwell commented Nov 18, 2015

@dcousens: consider, a couple weeks ago I learned sipa's rpcpassword while he was showing me something in his bitcoin.conf on his screen.

Hashed passwords were the norm for system authentication decades before encrypted transports. :)

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 18, 2015

Member

Concept ACK
Hashed passwords in the configuration file is definitely an improvement.

Member

laanwj commented Nov 18, 2015

Concept ACK
Hashed passwords in the configuration file is definitely an improvement.

@laanwj

View changes

contrib/rpcuser/rpcuser.py
@@ -0,0 +1,41 @@
+#!/usr/bin/env python3

This comment has been minimized.

@laanwj

laanwj Nov 18, 2015

Member

nit: If this script is supposed to be used by end users, it should be in share/ (I think) and be installed with make install. Contrib is usually for obscure things only useful for developers.

@laanwj

laanwj Nov 18, 2015

Member

nit: If this script is supposed to be used by end users, it should be in share/ (I think) and be installed with make install. Contrib is usually for obscure things only useful for developers.

This comment has been minimized.

@MarcoFalke

MarcoFalke Nov 18, 2015

Member

And mention in the readme how this should be called. E.g. ./rpcuser testUserName.

@MarcoFalke

MarcoFalke Nov 18, 2015

Member

And mention in the readme how this should be called. E.g. ./rpcuser testUserName.

This comment has been minimized.

@instagibbs

instagibbs Nov 18, 2015

Member

I don't see any related scripts in 'share' nor a readme in the folder.

@instagibbs

instagibbs Nov 18, 2015

Member

I don't see any related scripts in 'share' nor a readme in the folder.

@instagibbs

This comment has been minimized.

Show comment
Hide comment
@instagibbs

instagibbs Nov 18, 2015

Member

Axed the key stretching done as per discussion in bitcoin-core-dev IRC, removed openssl dependency. Updated description.

Member

instagibbs commented Nov 18, 2015

Axed the key stretching done as per discussion in bitcoin-core-dev IRC, removed openssl dependency. Updated description.

@instagibbs

This comment has been minimized.

Show comment
Hide comment
@instagibbs

instagibbs Nov 19, 2015

Member

Moved the python script to share directory.

Member

instagibbs commented Nov 19, 2015

Moved the python script to share directory.

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Nov 20, 2015

Member

Concept ACK

Member

jtimon commented Nov 20, 2015

Concept ACK

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Nov 20, 2015

Contributor

utACK

Contributor

dcousens commented Nov 20, 2015

utACK

@6coind

This comment has been minimized.

Show comment
Hide comment
@6coind

6coind Nov 20, 2015

Concept ACK +1 , finally !!!!

6coind commented Nov 20, 2015

Concept ACK +1 , finally !!!!

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Nov 23, 2015

Member

@instagibbs mind squashing some of this to get the EVP stuff out of the history?

Member

gmaxwell commented Nov 23, 2015

@instagibbs mind squashing some of this to get the EVP stuff out of the history?

@instagibbs

This comment has been minimized.

Show comment
Hide comment
@instagibbs

instagibbs Nov 23, 2015

Member

squashed

Member

instagibbs commented Nov 23, 2015

squashed

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Nov 23, 2015

Member

Hm. Python3 dep on the gen util. How hard would that be to avoid?

Member

gmaxwell commented Nov 23, 2015

Hm. Python3 dep on the gen util. How hard would that be to avoid?

@gavinandresen

This comment has been minimized.

Show comment
Hide comment
@gavinandresen

gavinandresen Nov 23, 2015

Contributor

New command-line or config-file options should be documented in the --help output (see init.cpp).

How does this interact with the automatic random cookie authentication in InitRPCAuthentication? I'd expect if I use -rpcauth that would be the only authentication method available...

And are changes to bitcoin-cli needed to add this new functionality?

In general, it makes me nervous to have two very different ways of accomplishing the same thing (-rpcauth and -rcpuser/-rpcpassword). Deprecating -rpcuser/-rpcpassword and moving to -rpcauth would be better, but even if deprecation doesn't happen in-memory conversion of any existing -rcpuser/-rpcpassword to the new scheme as one of the first things done at startup in any code that deals with those options should be less bug-prone.

Contributor

gavinandresen commented Nov 23, 2015

New command-line or config-file options should be documented in the --help output (see init.cpp).

How does this interact with the automatic random cookie authentication in InitRPCAuthentication? I'd expect if I use -rpcauth that would be the only authentication method available...

And are changes to bitcoin-cli needed to add this new functionality?

In general, it makes me nervous to have two very different ways of accomplishing the same thing (-rpcauth and -rcpuser/-rpcpassword). Deprecating -rpcuser/-rpcpassword and moving to -rpcauth would be better, but even if deprecation doesn't happen in-memory conversion of any existing -rcpuser/-rpcpassword to the new scheme as one of the first things done at startup in any code that deals with those options should be less bug-prone.

@instagibbs

This comment has been minimized.

Show comment
Hide comment
@instagibbs

instagibbs Nov 23, 2015

Member

@gmaxwell I've added a few more lines to make it work for either.

@gavinandresen To the connecting bitcoin-cli, the interface is just the same. That was intentional. And I'm in agreement about (eventual?) deprecation. It'd be quite easy to do after this. I'll add some documentation to init.cpp, sure.

Member

instagibbs commented Nov 23, 2015

@gmaxwell I've added a few more lines to make it work for either.

@gavinandresen To the connecting bitcoin-cli, the interface is just the same. That was intentional. And I'm in agreement about (eventual?) deprecation. It'd be quite easy to do after this. I'll add some documentation to init.cpp, sure.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Nov 23, 2015

Member

At least I was thinking that rpcuser/rpcpassword should be deprecated, but wasn't expecting that to happen right this instant.

For cookie auth, it can be useful to have both-- the reason is that cookie auth can be used seamlessly by local applications. But the correct way to achieve that is probably a soft opt disable for cookie auth triggered by having static authentication; I guess.

Member

gmaxwell commented Nov 23, 2015

At least I was thinking that rpcuser/rpcpassword should be deprecated, but wasn't expecting that to happen right this instant.

For cookie auth, it can be useful to have both-- the reason is that cookie auth can be used seamlessly by local applications. But the correct way to achieve that is probably a soft opt disable for cookie auth triggered by having static authentication; I guess.

@MarcoFalke

This comment has been minimized.

Show comment
Hide comment
@MarcoFalke

MarcoFalke Nov 23, 2015

Member

@instagibbs Mind to add the missing "-rpcauth" help message in init.cpp?

Member

MarcoFalke commented Nov 23, 2015

@instagibbs Mind to add the missing "-rpcauth" help message in init.cpp?

@instagibbs

This comment has been minimized.

Show comment
Hide comment
Member

instagibbs commented Nov 23, 2015

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Nov 24, 2015

Contributor

@gmaxwell we can at least add a warning for -rpcuser straight away?

Contributor

dcousens commented Nov 24, 2015

@gmaxwell we can at least add a warning for -rpcuser straight away?

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Nov 24, 2015

Member

@dcousens seems reasonable to me, also a good way to get uses moving to the cookie approach as applicable.

Member

gmaxwell commented Nov 24, 2015

@dcousens seems reasonable to me, also a good way to get uses moving to the cookie approach as applicable.

@instagibbs

This comment has been minimized.

Show comment
Hide comment
@instagibbs

instagibbs Nov 24, 2015

Member

@gavinandresen gave it some more thought, and I think it's most straight forward to throw a warning for now, then completely replace as a next step. By the time I get some intermediate step to work, it's just easier to replace everything in my opinion. Would that be acceptable?

Member

instagibbs commented Nov 24, 2015

@gavinandresen gave it some more thought, and I think it's most straight forward to throw a warning for now, then completely replace as a next step. By the time I get some intermediate step to work, it's just easier to replace everything in my opinion. Would that be acceptable?

@instagibbs

This comment has been minimized.

Show comment
Hide comment
@instagibbs

instagibbs Nov 27, 2015

Member

@dcousens: added a warning. Is this along the lines of what you were thinking?

Member

instagibbs commented Nov 27, 2015

@dcousens: added a warning. Is this along the lines of what you were thinking?

@gwillen

View changes

src/init.cpp
@@ -482,6 +482,7 @@ std::string HelpMessage(HelpMessageMode mode)
strUsage += HelpMessageOpt("-rpcbind=<addr>", _("Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6. This option can be specified multiple times (default: bind to all interfaces)"));
strUsage += HelpMessageOpt("-rpcuser=<user>", _("Username for JSON-RPC connections"));
strUsage += HelpMessageOpt("-rpcpassword=<pw>", _("Password for JSON-RPC connections"));
+ strUsage += HelpMessageOpt("-rpcauth=<userpw>", _("Username and hashed password for JSON-RPC connections. The field <userpw> comes in the format: <USERNAME>:<SALT>$<HASH>. A canonical python script is included in share/rpcuser"));

This comment has been minimized.

@gwillen

gwillen Nov 28, 2015

Contributor

Add 'This option can be specified multiple times.' for clarity?

@gwillen

gwillen Nov 28, 2015

Contributor

Add 'This option can be specified multiple times.' for clarity?

@gwillen

This comment has been minimized.

Show comment
Hide comment
@gwillen

gwillen Nov 28, 2015

Contributor

utACK with one nit in the help text (see above.)

Contributor

gwillen commented Nov 28, 2015

utACK with one nit in the help text (see above.)

@sipa

View changes

src/httprpc.cpp
+static bool multiUserAuthorized(std::string strUserPass)
+{
+ std::string strUser = strUserPass.substr(0, strUserPass.find(":"));
+ std::string strPass = strUserPass.substr(strUserPass.find(":") + 1);

This comment has been minimized.

@sipa

sipa Nov 28, 2015

Member

What happens when a client sends an authentication string that does not contain a ':'? My guess is that find returns npos == -1, which means that both strPass and strUser will be equal to strUserPass in that case. It looks harmless, but certainly unintuitive and perhaps not well-defined?

@sipa

sipa Nov 28, 2015

Member

What happens when a client sends an authentication string that does not contain a ':'? My guess is that find returns npos == -1, which means that both strPass and strUser will be equal to strUserPass in that case. It looks harmless, but certainly unintuitive and perhaps not well-defined?

@sipa

View changes

src/httprpc.cpp
+
+ CHMAC_SHA256(reinterpret_cast<const unsigned char*>(strSalt.c_str()), strSalt.size()).Write(reinterpret_cast<const unsigned char*>(strPass.c_str()), strPass.size()).Finalize(out);
+ for (int i=0;i<(int)KEY_SIZE;i++) {
+ sprintf(outhex+(i*2), "%02x", out[i]);

This comment has been minimized.

@sipa

sipa Nov 28, 2015

Member

You can use HexStr() from utilstrencodings.h here.

@sipa

sipa Nov 28, 2015

Member

You can use HexStr() from utilstrencodings.h here.

This comment has been minimized.

@instagibbs

instagibbs Nov 28, 2015

Member

Thanks for the tip.

@instagibbs

instagibbs Nov 28, 2015

Member

Thanks for the tip.

@gwillen

This comment has been minimized.

Show comment
Hide comment
@gwillen

gwillen Nov 29, 2015

Contributor

Seems like all mentioned issues are now fixed. I'd love to see this get merged before the 0.12 freeze.

Contributor

gwillen commented Nov 29, 2015

Seems like all mentioned issues are now fixed. I'd love to see this get merged before the 0.12 freeze.

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Nov 30, 2015

Contributor

@instagibbs warning LGTM 👍

Contributor

dcousens commented Nov 30, 2015

@instagibbs warning LGTM 👍

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Nov 30, 2015

Contributor

re-ACK

Contributor

dcousens commented Nov 30, 2015

re-ACK

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Nov 30, 2015

Member

Tested ACK

Member

btcdrak commented Nov 30, 2015

Tested ACK

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Nov 30, 2015

Member

ACK

Member

gmaxwell commented Nov 30, 2015

ACK

@gmaxwell gmaxwell merged commit d52fbf0 into bitcoin:master Nov 30, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

gmaxwell added a commit that referenced this pull request Nov 30, 2015

Merge pull request #7044
d52fbf0 Added additional config option for multiple RPC users. (Gregory Sanders)

@VoidingWarranties VoidingWarranties referenced this pull request in NebulousLabs/Sia Apr 14, 2016

Closed

API authentication #1065

zkbot added a commit to zcash/zcash that referenced this pull request Mar 21, 2018

Auto merge of #2390 - str4d:2132-mapargs-prep, r=<try>
Misc upstream PRs

Cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#6077
  - Second commit only (first was already applied to 0.11.X and then reverted)
- bitcoin/bitcoin#6284
- bitcoin/bitcoin#6489
- bitcoin/bitcoin#6462
- bitcoin/bitcoin#6647
- bitcoin/bitcoin#6235
- bitcoin/bitcoin#6905
- bitcoin/bitcoin#6780
  - Excluding second commit (QT) and third commit (requires bitcoin/bitcoin#6993)
- bitcoin/bitcoin#6961
  - Excluding QT parts, and a small `src/policy/policy.cpp` change which depends on a bunch of other PRs, which we'll have to remember to come back to.
- bitcoin/bitcoin#7044
- bitcoin/bitcoin#8856
- bitcoin/bitcoin#9002

Part of #2074 and #2132.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment