A new Pin class is provided to create secure password dialogs using process separation.
IPC is done via libassuan and the assuan daemon user is standard pinentry (portable qt, gtk2 and ncurses implementations are available)
Pinentry takes care of memlocking and is the standard for GNUPG.
The Pin class is designed to be readable and well reusable in other password entry tasks.
This commit adds optional build dependency from libassuan and optional runtime dependency from a pinentry daemon.
A new class Pin is used to create secure password dialogs using
process separation.
IPC is done via libassuan and the assuan daemon user is standard
pinentry (portable qt, gtk2 and ncurses implementations are available)
Pinentry takes care of memlocking and is the standard for GNUPG.
So...this adds the option to specify the rpcuser/pass at runtim instead of via -rpcuser/-rpcpassword. I like this.
However, why use ASSUAN? Assuan takes care of mlock() and such, but how hard is that, really, to do ourselves? I'm not a huge fan of adding another dependency, though I suppose the fact that it is optional is nice. If we are just using the cli input from assuan, and not all their other wx stuff, how hard would it be to copy/paste the probably 20 relevant lines from assuan, or rewrite them ourselves?
ASSUAN might be useful for wallet crypto, where the user needs to enter their password via GUI and I have yet to find a way to mlock() the password as the user enters it, but even still, the attack which mlock() protects against is almost never seen in the wild. Assuan is designed to be a secure method of IPC, but in this case it is just used as a password entry library. Assuan might be very useful for something like libbitcoin, but for bitcoin it seems like far over-engineering.
Maybe Im missing something you can point out?
Maybe assuan also tries to stop keyloggers on Windows, but my short googleing seemed to indicate otherwise.
It is Pinentry, main reference implementation of an assuan daemon, that tries to stop software keyloggers when started as a separate process, capturing exclusive focus and such. The whole architecture of this system for user input looks very reliable, portable and promising to me. Researching into it gave me quite some satisfaction :^)
My guess is that, since it is all ported on major platforms, this new small dependency wouldn't be a problem (at least as optional) and can provide a solid platform to develop further on situations that require user input in bitcoin (which is totally lacking ATM); as you can see the Pin class is very simple and well readable.
Its not a question of whether a new dep will cause problems in compiling, but a question of is it necessary? A new dep just means that much more work when compiling and that much more memory used when it has to be loaded.
I agree assuan looks like a good lib to input password, but again...why? It would be great to have when we move towards libbitcoin, but that is such a long way off I dont see any use in this for some time to come.
I definitely see the usefulness of introducing ssh-askpass style support for bitcoind. It makes, for instance, setting a one-time use passphrase for txn creation using your new wallet encryption code much much simpler.
However, I cannot get this to build cleanly with the version of libassuan in debian stable. What exactly are the build deps?
on Ubuntu packaged deps are libassuan2-dev and libgpg-error-dev of course you must uncomment USE_ASSUAN in makefile.unix (later that can be --enable-pinentry on autotools)
just tested compilation on Debian 6.0 and you are right, doesn't works: Debian is stuck to the old libassuan-dev (version 1)
my approach in this case is include statically and then move strings so that Debian wakes up, which takes time indeed..
forgot to mention that i'm available to fix this up to work on libassuan 1 or 2, yet before doing that i'd like to know if there is reasonable intention to pull this into mainline or not, just lemme know
I know I would like to see it pulled.
you should add libassuan-dev to the apt-get instructions if this should be pulled
where is the libassuan project homepage? Is it part of something else?
Its a part of GPG and afaict mostly just used by that.
http://www.gnupg.org/download/#libassuan http://www.linuxfromscratch.org/blfs/view/cvs/general/libassuan.html
The Debian archive contains a few other packages using libassuan:
apt-cache rdepends libassuan0
libassuan0
Reverse Depends:
scute
libassuan0-dbg
libassuan-dev
gpgsm
gnupg2
gnupg-agent
dirmngr
yes, ASSUAN is a new, well thought and documented protocol for secure IPC by the fine people coding on GNUPG which will arguably become a de facto standard in future.
the provision of pinentry-* programs on various platforms makes it extremely convenient to use it to implement password prompt
my current code uses the ASSUAN-2 API which contains some design improvements over the version 1, although it can be downgraded for full compatibility since debian still has the older library packaged, or detected at compile time once autoconf build is there.
i can do that but again first i'd like to know if this is a feature you are willing to pull or not, since this is mostly a design issue that can affect future development (which should then arguably stick to these set of dependencies for tasks as password prompt).
I like the feature, but won't pull for two reasons:
re: point 2 - what is under the GNU GPL?
the code i'm contributing is licensed under the same MIT license as Bitcoin.
you mean the dependencies? is your intention to avoid any library dependency licensed as GNU GPL?
Yes, we avoid an GPL library dependencies. LGPL is OK.
But libassaun is gplv2+ OR lgplv2+ ?
Actually, I'm wrong. From the README the source is straight up lgplv2. (The rest of the gnupg packages are gplv2+.)
See COPYING.LIB on how to share, modify and distribute the software itself (LGPLv2.1+) and COPYING for the documentation (GPLv3+).