< jl2012>
gmaxwell, luke-jr: I think we could require an extra command in debug windows to "unlock" those sensitive commands
< CodeShark>
jl2012: good idea
< jl2012>
which will return a page of warning, describing the risk of each unlocked command
< luke-jr>
jl2012: hmm, that might work
< GitHub144>
[bitcoin] petertodd opened pull request #8543: Use ANYONECANPAY if -spendzeroconfchange=0 (master...2016-08-anyonecanpay-if-spendzeroconfchange-disabled) https://github.com/bitcoin/bitcoin/pull/8543
< jonasschnelli>
sipa, gmaxwell: about the binary ecdsa signing. We could create a standard ecdsa sig along with the GPG assets sig. Something like bitcoin-osx-0.13-build.assert.ecsig, where we just place a 64byte compact sig. ecdsa(sha256(sha256(<filecontent>)), P)
< jonasschnelli>
sipa, gmaxwell: then we could have a file with [{"<devname>":"34byte pubkey"},]
< jonasschnelli>
(a cpp header IMO)
< jonasschnelli>
For the downloading the asset file signatures, we could use the github API (GET /repos/:owner/:repo/contents/:path)
< jonasschnelli>
Using the maybe existing local git binary seems fragile
< luke-jr>
Seems unlikely Mac/Windows (where this will generally get used) will have a local git binary anyway
< jonasschnelli>
luke-jr: Yes. depending on git is probably a nogo on Win/OSX
< da2ce7>
jonasschnelli a ecdsa binary verify client would be very useful for other projects. It would be great to create something that could get support of a wider community.
< jonasschnelli>
Yes. Maybe it could be coupled with gitian
< da2ce7>
I would have something like a 'project definition' file. that defines the fields: serial, project name, version naming rules, public keys, n of m requirements, revoked keys, revoked releases
< da2ce7>
and a 'witness file', that has a list of sha256 hashes, and signatures.
< jonasschnelli>
You need to make sure the "project definition" (devs pubkey) must be covered by a sha256 during previous builds...
< jonasschnelli>
This why it might be best if compiled into a binary or if its covered in the gitian assets file
< da2ce7>
the project definition file should come with a self-witness, except that the self-witness is signed by all of the public keys defined in the definition.
< da2ce7>
(ignores the n-of-m requirement).
< catsAREnotSECURE>
Is there public disclosure of bitcoin holdings / wallets associated with specific developers?
< da2ce7>
catsAREnotSECURE no, and off topic.
< catsAREnotSECURE>
This question was intended for midnightmagic. The conversation began in #bitcoin, but for transparency reasons, I sought to move it to this channel.
< da2ce7>
catsAREnotSECURE, well, I'm sorry for your mistake, please move it back to #bitcoin, or elsewhere.
< catsAREnotSECURE>
One more comment and then that will be it.
< catsAREnotSECURE>
midnightmagic, During the last meeting, there was discussion regarding the proposed implementation a system similar to that which Gitian is using, which features signatures of multiple developers, within the official binary / source distribution on certain operating systems. One proposal included distributing the GPG library and another used an alternate method for signature / checksum verification which would not require additional
< catsAREnotSECURE>
libraries. The alternate proposal, determined by Wladimir van der Laan to be unworkable, intended to mitigate the requirement of an additional library by imbedding checksums within the blockchain. The alternate proposal was not included in the official meeting and was dismissed over stated concerns about existing nodes rejecting the transactions. It was acknowledged that either implementation would significantly increase client
< catsAREnotSECURE>
security during the release cycle, affecting the majority of users, and it is speculated by my clients that either implementation would result in less (downward) price fluctuation. Right now, the security of the releases are highly dependant on admittedly vulnerable CA/TLS certificates and a single GPG signing key held by Wladimir van der Laan, with a lack of transparency regarding the level of security measures taken to secure this
< catsAREnotSECURE>
signing key. During this "unofficial" meeting in #bitcoin, there were a minimum of 123 lines of comment from Wladimir van der Laan, all of which are not included in the "official" meeting log. Given the recent advisory on the website, regarding "state actors", there is speculation amoung my clients that conflict of interest disclosure and transparency may be insufficient amoung the Bitcoin Core developers.
<@sipa>
catsAREnotSECURE: take it elsewhere
< luke-jr>
then your clients should hire people of their own to work as Bitcoin Core developers; off-topic anyway, #bitcoin
< jonasschnelli>
sigh
< da2ce7>
jonasschnelli we need a constant 'Project CN', so that somebody doesn't release 'bitcotn-core' and project will ignore all the signing policies. - The verify app should also spit out warnings: "bitcotn-core" is very similar to "bitcoin-core".
< da2ce7>
maybe a simple 'release' file will suffice. a release file has: project CN, sha256 of latest 'project definition' file, release name and version, list of sha256 of past release files, list of sha256 of binaries included in release
< wumpus>
gmaxwell: god damnit, can it get any more scammy
< MarcoFalke>
?
< wumpus>
<gmaxwell> Someone in #bitcoin had 17 BTC stolen from them today because they came for tech support (their wallet was a couple years behind and they were wondering why they hadn't seen a payment yet) and someone wumpus and I were talking to, "moldish", pulled them into PM and got them to do a dumpprivkey. :(
< LeMiner>
ugh...
<@sipa>
:(
< wumpus>
fuckers
<@sipa>
do we need to put a warning in the qt console when using certain RPCs?
< LeMiner>
could include a warning message on dumbprivkey that the outputs are private and anyone with the key can steal your coins?
< LeMiner>
exactly
< wumpus>
does anyone have info on that guy?
<@sipa>
of course, then people may get users to run bitcoin-qt with -server...
< midnightmagic>
wumpus: Yes. A tenuous link.
< LeMiner>
Not a bad idea
< luke-jr>
sipa: jl2012 suggested an extra step to enable dangerous RPCs
< luke-jr>
(which would warn)
< wumpus>
luke-jr: +1
< wumpus>
I think any private key leaking functions should be disabled by default
< LeMiner>
And perhaps a topic message in #bitcoin that states to be cautious when people try to "help" you through pm's
< wumpus>
both for the UI and RPC
< * midnightmagic>
will change the topic immediately.
< wumpus>
maybe a command line option to enable them
< sipa>
LeMiner: nobody reada the topic message, but it can't hurt
< wumpus>
jcorgan: not really, I try to get back to that at some point
< wumpus>
jcorgan: lots of things got in between, as usual :(
< jouke>
But, literally at the same time we were helping a customer on the phone to do a dumpprivkey :x. (Someone bought bitcoins to pay for cryptolocker, but didn't realise that it would take a while for Core to be able to send bitcoins).
< wumpus>
"Someone bought bitcoins to pay for cryptolocker" :(
< wumpus>
I'm going to take off today, sorry
< jouke>
heh
< wumpus>
stupid fuckers, sometimes I'm about to believe the story that bitcoin is just making it easy for people to be scammed out of their money
< jonasschnelli>
Private-key-management will occupy us during the next years...
< jonasschnelli>
But people also need to wake up...
< wumpus>
yes, people need to take responsibility, or not use it at all
< jonasschnelli>
Would you give someone (just met on the street), you wallet containing 10k USD to "fix an issue" with the opening zipper?
< wumpus>
but things like cryptolocker ... bah puke
< jonasschnelli>
Cryptolockers are evil, ... indeed.
< wumpus>
jonasschnelli: not a random someone, but what if someone pretends to be e.g. a cop, people would be inclined to trust them
< jonasschnelli>
maybe in Europe. :) But right,... people pretending to help on technical issues but then scam off one, thats just so bad.
< wumpus>
but yes the threshold for trust should be even lower on the internet, you can almost never assume peopel are who them pretend they are
< wumpus>
that's a much bigger problem than just bitcoin
< jouke>
A lot of people are really trustful by nature.
< jonasschnelli>
which is good IMO
< jouke>
They should wake up indeed. But I lost a bit of confidence in "people" to be able to do so since I started with Bitcoin. On the other hand, a police officer once told me: "These people are allowed to vote".
< jonasschnelli>
But I agree with wumpus, we should add some private key protections
< jonasschnelli>
But the questions is then, if an attacker can manage to enable the protected features by setting a config value, etc.
< jonasschnelli>
(if they already manage to execute dumpprivkey)
< jonasschnelli>
Maybe warning are the better approach
< jonasschnelli>
you need to call dumpprivkey twice...
< jonasschnelli>
first time, it will response with a warning
< wumpus>
a big red warning on top of the debug console
< jouke>
Only to come to realise that people don't read :P
< jonasschnelli>
or we could entirely disable dumpprivkey in the GUI
< jonasschnelli>
(and dumpwallet)
< jonasschnelli>
like most hardware wallets, there is no way to export private keys.
< jonasschnelli>
(for core, except your using -server/d with bitcoin-cli
< gmaxwell>
Requiring QT is problematic, since many (esp high security) users are headless cli users. This sounds like it is not (many) fewer steps then verifying with gpg? it sounds like you're thinking the user will seperately download the software, but then verify it with this which will also make outbound connections?
< gmaxwell>
My suggestion is that we make it so there is a single download which contains all the verification information. Just one file. And have it so the tool can either take this one file provided by the user and verify it and if it passes, unpack and install it, or it can fetch it + verify it (then unpack and install it).
< gmaxwell>
it's important that its also easy to use the tool without it making network connections, so that it can be used on offline hosts, and also not "phone home" every time bitcoin is installed, which would make it easy to track who is using it. (both who is using bitcoin and who is using it with/without verifying-- we want a network attacker to not be able to tell users who verify from users who don'
< gmaxwell>
t)
< jonasschnelli>
gmaxwell: Good point.. make sense.
< jonasschnelli>
gmaxwell: regarding "single download", Isn't grabbing the sources from a GPG signed github repository more secure?
< jonasschnelli>
Hmm... no... not really
< jonasschnelli>
Agree, we could provide a single witness file along with the binaries
< jonasschnelli>
If additional signature follow after the release, we could update the witness file.
< gmaxwell>
then thats two files, which would be unfortunate (bad for usability)
< jonasschnelli>
What would speak against replacing the witness file...
< jonasschnelli>
?
< jonasschnelli>
gmaxwell: Or do you mean a "single download" would be the verifing tool including the witness data?
< gmaxwell>
By two files I mean "bitcoin" and "the witness" if there are two files someone watching the network can tell which users check and which don't, and someone checking on an offline computer has two files to download and copy across, so they won't.
< gmaxwell>
I mean the bitcoin core update and the signatures for it should be a single file. The download/verifying tool can both be included in it, and available seperately (for the first time user).
< jonasschnelli>
ah...
< jonasschnelli>
yes..
< jonasschnelli>
Though, there would be a file-package (including sigs) per platform I guess
< gmaxwell>
Right, I guess I'd suggest we include in the tar a dummy file the size of the witness. And the signing tool would fill that in, and the verify tool would mask out the dummy file. Or something like that.
< gmaxwell>
it's a little unfortunate to have to uncompress an unverified file, but I see no way around that.
< jonasschnelli>
or just <whitnessfile>&<tar.file>
< gmaxwell>
do you mean concatinate them?
< jonasschnelli>
It would be a "new file format"... but I guess that doesn't matter
< jonasschnelli>
yes
< jonasschnelli>
also it prevents from users extracting the tar without verifing.
< jonasschnelli>
Once it was verified, it'll copy out the "pure" tag
< jonasschnelli>
tar
< gmaxwell>
well that would be simpler, unfortunately it would mean a network observer could tell who was downloading those files vs the plain tar files, unless we stopped distributing plain tar files.
< gmaxwell>
I do like that that is much easier to implement. :)
< jonasschnelli>
stopping the plain tar files would probably good, but people will complain. :)
< jonasschnelli>
*be good
< jonasschnelli>
I think forcing user to verify the binaries would be good security pratice.
< gmaxwell>
Yes, but using a web wallet because bitcoin core install required an extra, foreign, step would not be. :)
< jonasschnelli>
indeed...
< gmaxwell>
my expectation is that users would use a traditional, insecure method to do their first install. You really can't do better than that, since even the verify tool itself would need to be installed.
< jonasschnelli>
Assume the signatures file is in the tar,.. I guess you can just extract a single file
< gmaxwell>
jonasschnelli: yes, the trickyness is with verifying you need to verify everything except that file. Which means masking it out.
< jonasschnelli>
Yes. First install of the verify tool should be verified through gitian-verify
< sipa>
do we need a tar parser then...?
< jonasschnelli>
Hmm.. tar dependency would be bad I guess
< jonasschnelli>
Can we not just append the signatures files to the tar so that the tar can still be deflated properly?
< gmaxwell>
we could start distibuing the software as shell archives, much easier to extract data from them. :P
< jonasschnelli>
A tar.gz that includes the binary as a tar.gz and the signatures?
< jonasschnelli>
we provide signatures only for the "inner" binary tar.gz
< jonasschnelli>
and would also work with the OSX .dmg and window .exe
< kanzure>
user can open a port on their machine, provide a login to the ripple foundation, and then the ethereum team can deliver the payload in one step
< kanzure>
sltar looks cool. this might even be human-memorizable.
< wumpus>
why would the signature files need to be in a tar?
< wumpus>
just go old school, concatenate binary ecdsa signatures
< jonasschnelli>
to avoid network observers to detect who download the signatures and who not as gmaxwell mentioned
< wumpus>
yes, well, it doesn't matter in what format it is then right?
< jonasschnelli>
wumpus: but that would require to split of the signatures if you just want to install it without verifing
< wumpus>
the user has to download the file with signatures anyhow
< kanzure>
i thought the concern was re: have a single download
< jonasschnelli>
wumpus: not if we make the verification optional
< wumpus>
attaching signatures to the download itself isn't really an option; this would invalidate the sha256 hashes
< jonasschnelli>
and would you also add the signatures to the .exe NSI installer? :)
< wumpus>
no
< jonasschnelli>
Just provide a "meta"-tar that includes the exe/dmg/tar.gz (where we provide hashes/sigs)
< wumpus>
just a replacement/addition to sha256sums.txt, that contains ecdsa signatures connected from by all gitian builders
< wumpus>
coLLected
< jonasschnelli>
Also fine for me.
< jonasschnelli>
gmaxwell said we should use just a single download
< wumpus>
that would be one additional file in addition to the one you want
< jonasschnelli>
to avoid network observers to detect who did download the sigs and who not
< wumpus>
sigh
< jonasschnelli>
hehe.. :)
< wumpus>
I can just smell the scope creep
< wumpus>
don't let gmaxwell get involved in this except for security review :)
< jonasschnelli>
We could start with an additional signatures file (per release including all platforms/binaries)
< kanzure>
re: "one additional file" -- i thought that was the point of tar? :)
< wumpus>
otherwise we'll never have an actually deployable product, just a lot of nice theory
< wumpus>
:P
< jonasschnelli>
though, that signature file may be changed after a release if we get additional signatures
< wumpus>
yes, additional signatures could be added to that file
< jonasschnelli>
But its a manual process I guess... which sucks
< wumpus>
it's just a concatentation of people's signatures of the same thing
< jonasschnelli>
The gitian.sig repo would probably be simpler
< wumpus>
could be fully automated
< wumpus>
python scirpt that pulls stuff from git
< wumpus>
concatenates it
< jonasschnelli>
Yes. Why not
< wumpus>
drops it on the site
< wumpus>
voila
< jonasschnelli>
But not sure if the site is protected with some non-automatable 2FA technique or so.
< wumpus>
could run in a crontab such
< wumpus>
it could be any site
< jonasschnelli>
crontab means the credentials must be available on that machine
< wumpus>
where to drop the signatures? that's a good question
< jonasschnelli>
yes. Could be a different site
< wumpus>
heck, it could be a githib statically hosted site
< jonasschnelli>
indeed
< wumpus>
laanwj.github.com/bla
< jonasschnelli>
Even simpler... it could be in gitian.sigs
< jonasschnelli>
or yes... on a static site
< wumpus>
could be, but rememer it needs to be a static http site
< wumpus>
putting it on github has the https probem again
< wumpus>
well, I mean as a git-based on github
< wumpus>
github static sites are http
< jonasschnelli>
We could add libcurl to our dependencies... *duck*
< wumpus>
:-(
< jonasschnelli>
But wait!
< jonasschnelli>
We could use Qt headless
< jonasschnelli>
no need to build windows.
< wumpus>
the point would be to make the user download it themselves I think
< wumpus>
if it needs to work without network conenction
< jonasschnelli>
both could be possible...
< wumpus>
or just use libevent's http client?
< wumpus>
we already have that
< jonasschnelli>
Yes. Why not...
< wumpus>
it's super-simple, but good enough to fetch a simple small binary or text file, if you really want
< wumpus>
(over http though, forget https)
< wumpus>
we have secp256k1 for signature verification, we have sha256 hashing, and we can fetch files over http through evhttp. I think all the components are there
< jonasschnelli>
Yes
< wumpus>
(that doesn't mean the implementation is trivial! but let's not talk about adding dependencies :-)
< jonasschnelli>
On OSX and Windows, the verify tool should probably have a GUI
< wumpus>
it also doesn't need to rely on qt, although for end-users a qt user interface for it would be nice
< wumpus>
ye
< jonasschnelli>
We could detect the platform (or maybe if a WM is attached on Linux) and create a UI in that case
< jonasschnelli>
Or..
< jonasschnelli>
we provide the verification-feature in Bitcoin-Qt and in the new cli only verify tool
< wumpus>
yea, or have separate verification-cli and verification-gui executables
< jonasschnelli>
or that. yes
< wumpus>
right, that is possible too
< jonasschnelli>
But another GUI tool would require some tweaks in the EXE/DMG deployment
< wumpus>
it has the advantage of not having to package qt twice, as long as we still statically lnk
< wumpus>
right, and that
< wumpus>
so having only one GUI executable which has it as extra menu option would be better probably
< jonasschnelli>
Ah. Yes
< jonasschnelli>
Indeed
< wumpus>
then have a seprrate cli verification executable
< jonasschnelli>
Okay... will try to work out something...
< wumpus>
thanks!
< jonasschnelli>
For creating the signatures, I guess it can be a third party tool.. don't need to be part of Bitcoin-Core
< wumpus>
certainly not
< wumpus>
I'll just roll some script for that, don't worry about that side :)
< wumpus>
I'll have a try at the gitian builder side
< wumpus>
(I wasn't serious about gmaxwell, to be clear)
< gmaxwell>
Why would we create a shitty NIH version of the openbsd signify tool?
< gmaxwell>
There is no security advantage from just changing the underlying cryptosystem.
< wumpus>
it's just easier to integrate in our software than using gpg
< wumpus>
if we could integrate a gpg lib and fetch the signatures from gitian.sigs repository and verify directly (like gitian-downloader) it'd be much more straightforward, but we need something that can be integrated into our software release right?
< GitHub196>
[bitcoin] MarcoFalke opened pull request #8548: [wallet] Use __func__ to get function name for output printing (master...Mf1608-walletFunc) https://github.com/bitcoin/bitcoin/pull/8548