More info regarding KeePass: http://keepass.info/
KeePass integration will use KeePassHttp (https://github.com/pfn/keepasshttp/) to facilitate communications between the client and KeePass. KeePassHttp is a plugin for KeePass 2.x and provides a secure means of exposing KeePass entries via HTTP for clients to consume.
The implementation is dependent on the following:
- crypter.h for AES encryption helper functions.
- rpcprotocol.h for handling RPC communications. Could only be used partially however due some static values in the code.
- OpenSSL for base64 encoding. regular util.h libraries were not used for base64 encoding/decoding since they do not use secure allocation.
- JSON Spirit for reading / writing RPC communications
The following changes were made:
- Added CLI options in help
- Added RPC commands: keepass <genkey|init|setpassphrase>
- Added keepass.h and keepass.cpp which hold the integration routines
- Modified rpcwallet.cpp to support RPC commands
The following new options are available for darkcoind and darkcoin-qt:
-keepass Use KeePass 2 integration using KeePassHttp plugin (default: 0)
-keepassport=<port> Connect to KeePassHttp on port <port> (default: 19455)
-keepasskey=<key> KeePassHttp key for AES encrypted communication with KeePass
-keepassid=<name> KeePassHttp id for the established association
-keepassname=<name> Name to construct url for KeePass entry that stores the wallet passphrase
The following rpc commands are available:
- keepass genkey: generates a base64 encoded 256 bit AES key that can be used for the communication with KeePassHttp. Only necessary for manual configuration. Use init for automatic configuration.
- keepass init: sets up the association between darkcoind and keepass by generating an AES key and sending an association message to KeePassHttp. This will trigger KeePass to ask for an Id for the association. Returns the association and the base64 encoded string for the AES key.
- keepass setpassphrase <passphrase>: updates the passphrase in KeePassHttp to a new value. This should match the passphrase you intend to use for the wallet. Please note that the standard RPC commands walletpassphrasechange and the wallet encrption from the QT GUI already send the updates to KeePassHttp, so this is only necessary for manual manipulation of the password.
Sample initialization flow from darkcoin-qt console (this needs to be done only once to set up the association):
- Have KeePass running with an open database
- Start darkcoin-qt
- Open console
- type: "keepass init" in darkcoin-qt console
- (keepass pops up and asks for an association id, fill that in). Example: mydrkwallet
- response: Association successful. Id: mydrkwalletdarkcoin - Key: AgQkcs6cI7v9tlSYKjG/+s8wJrGALHl3jLosJpPLzUE=
- Edit darkcoin.conf and fill in these values
keepass=1
keepasskey=AgQkcs6cI7v9tlSYKjG/+s8wJrGALHl3jLosJpPLzUE=
keepassid=mydrkwallet
keepassname=testwallet
- Restart darkcoin-qt
At this point, the association is made. The next action depends on your particular situation:
- current wallet is not yet encrypted. Encrypting the wallet will trigger the integration and stores the password in KeePass (Under the 'KeePassHttp Passwords' group, named after keepassname.
- current wallet is already encrypted: use "keepass setpassphrase <passphrase>" to store the passphrase in KeePass.
At this point, the passphrase is stored in KeePassHttp. When Unlocking the wallet, one can use keepass as the passphrase to trigger retrieval of the password. This works from the RPC commands as well as the GUI.
The following mining-related RPC calls don't use the wallet:
- getnetworkhashps
- getmininginfo
- getblocktemplate
- submitblock
Enable them when compiling with --disable-wallet.
26d1b65 src/Makefile.am: Simplify clean of leveldb (Josh Triplett)
a26a367 configure.ac: Check for miniupnpc headers, not just -lminiupnpc (Josh Triplett)
82ccb05 autogen.sh: Stop passing --verbose to autoreconf (Josh Triplett)
e12dafd autogen.sh: Use long options to autoreconf, for self-documentation (Josh Triplett)
19b9add autogen.sh: Support running from outside the source directory (Josh Triplett)
97d285a autogen.sh: Use set -e to fail if any command fails (Josh Triplett)
f80b723 autogen.sh: Add a /bin/sh shebang. (Josh Triplett)
Remove unnecessary dependencies for bitcoin-cli
(leveldb, berkelydb, wallet, RPC server)
Build system changes:
- split libbitcoin.a into libbitcoin_common.a, libbitcoin_server.a and
libbitcoin_cli.a
Code changes (movement only):
- split up HelpMessage into HelpMessage in init.cpp and HelpMessageCli
in rpcclient.cpp
- move uiInterface from init.cpp to util.cpp
Split bitcoinrpc up into
- rpcserver: bitcoind RPC server
- rpcclient: bitcoin-cli RPC client
- rpcprotocol: shared common HTTP/JSON-RPC protocol code
One step towards making bitcoin-cli independent from the rest
of the code, and thus a smaller executable that doesn't have to
be linked against leveldb.
This commit only does code movement, there are no functional changes.
Use misc methods of avoiding unnecesary header includes.
Replace int typedefs with int##_t from stdint.h.
Replace PRI64[xdu] with PRI[xdu]64 from inttypes.h.
Normalize QT_VERSION ifs where possible.
Resolve some indirect dependencies as direct ones.
Remove extern declarations from .cpp files.
This adds an executable `bitcoin-rpc` that only serves as a Bitcoin RPC
client.
The commit does not remove RPC functionality from the `bitcoind` yet,
this functionality should be deprecated but is left for a later version
to give users some time to switch.
Create an allocators.cpp, and move all of the #ifdef WIN32
code and the #include of windows.h into it.
Two motives for this cleanup:
1. I'm getting a weird error in windows.h in my smartfee branch.
2. allocators.h is included (indirectly) just about everywhere, so
this should speed up Windows compiles quite a lot.
This change moves test data into the binaries rather than reading them from
the disk at runtime.
Advantages:
- Tests become distributable
- Cross-compile friendly. Build on one machine and execute in an arbitrary
location on another.
- Easier testing for backports. Users can verify that tests pass without having
to track down corresponding test data.
- More trustworthy test results and easier quality assurance as tests make
fewer assumptions about their environment.
- Tests could theoretically run at client/daemon startup and exit on failure.
Disadvantages:
- Required 'hexdump' build-dependency. This is a standard bsd tool that should
be usable everywhere. It is likely already installed on all build-machines.
- Tests can no longer be fudged after build by altering test-data.
libleveldb.a and libmemenv.a should be able to build in parallel, but in
practice calling the leveldb makefile ends up rewriting build_config.mk. If
one target tries to build while the other is halfway through writing the
.mk, the make ends up in an undefined state.
Fix that by making one depend on the other. This also reorders the variables
to be passed by param rather than via the environment, and combines the targets
into a single rule to avoid needless duplication.
