< benthecarman>
Is the mailing list down? It won't let me add myself
< wajz>
Hi there!, just a simple question. I'm reading a blockchain paper which I would like to discuss. Is this an appropiate channel or there's any 'research channel'?
< kanzure>
/join #bitcoin-wizards
< wajz>
Thanks kanzure
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #15169: WIP: Parallelize CheckInputs() in AcceptToMemoryPool() (master...2018-12-parallel-mempool-scriptchecks) https://github.com/bitcoin/bitcoin/pull/15169
< bitcoin-git>
[bitcoin] koalaman opened pull request #15170: refactor/lint: Add ignored shellcheck suggestions to an array (master...master) https://github.com/bitcoin/bitcoin/pull/15170
< meshcollider>
gwillen: maybe only one or two more, hopefully promag or someone who commented early on is willing to do a full review
< gwillen>
meshcollider: cool, thanks
< gwillen>
I would ping promag here but he doesn't seem to be on at the moment
< meshcollider>
He'll get pinged by my message anyway :)
< gwillen>
well he would if he were here, anyway :-)
< gmaxwell>
Security warning: if you scp files from a malicious ssh server, it can overwrite arbritary files in/under your target directory.
< DeanGuss>
so you're saying don't work with malicious ssh servers?
< booyah>
gmaxwell: that seems like a serious bug. you are not controling the file name? scp foo@bar.org:/tmp/a.txt ./ can result in something else then ./a.txt ?
< cjd>
that's what it sounds like
< cjd>
or worse, a.txt as you expected plus also click_here_please.exe as well
< cjd>
or .bashrc or any of a plethora of other nasties
< wumpus>
wonder if rsync has the same problem? that's what I usually yse
< cjd>
hmm, my intuition is that ssh to malicious machines is a minefield
< promag>
#14941 should be ready for last ack and merge
< wumpus>
but do you ever know for sure that the machine you're sshing to is not 'malicious'? if exploits can easily travel from ssh servers to clients, this makes e.g. VMs mostly useless as an isolation mechanism
< wumpus>
but yes, if you know you're sshing to a compromised machine it's good to be careful I guess
< luke-jr>
wumpus: rsync supports wildcards, so I suspect it has the same problem :/
< luke-jr>
eg, rsync foo@bar:/path/to/\* ./
< wumpus>
hmm true, but if you use a wildcard you're kind of asking for the remote to be able to overwrite any file locally (unless you provide the flag not to)
< wumpus>
well any file within the destination path obviously not outside it
< luke-jr>
wumpus: yes, but that feature implies the local client needs to do its own globbing check
< wumpus>
luke-jr: but the remote can always lie about which files are available, I'd think
< wumpus>
oh you mean to match against the globs, of course
< gkrizek>
wumpus: no, I commented about it when it started up yesterday. "GitHub IRC Service is out of its brown out until the 31st when it’s fully depreciated. I’m still working on a replacement and it’s close to done. Will def be done before the 31st."
< gkrizek>
So it's still GitHub back for a couple weeks before it's really really dead
< wumpus>
gkrizek: okay ! thanks again for working on it
< wumpus>
apparently missed that comment :)
< gkrizek>
No problem, happy to do it!
< promag>
wumpus: on it
< promag>
wumpus: #14958 could also go
< gribble>
https://github.com/bitcoin/bitcoin/issues/14958 | qa: Remove race between conneting and shutdown on separate connections by promag · Pull Request #14958 · bitcoin/bitcoin · GitHub
< wumpus>
ook
< wumpus>
would be nice if MarcoFalke could take a look at that one
< promag>
no problem
< promag>
there's like 1 month until feature freeze?
< luke-jr>
at the very least it could be uint64_t(1)
< luke-jr>
FWIW, I confirmed rsync IS vulnerable to the same
< wumpus>
luke-jr: thanks for the suggestion, will try
< luke-jr>
(to reproduce, make a dummy shell script that just does exec ${SSH_ORIGINAL_COMMAND/dummyA\/a/dummyA\/*}, and use SSH forced commands to call it)
< sipa>
wumpus: so it's counting from 2**(i-1) to (2**i)-1 ?
< phantomcircuit>
wumpus, remote can also send sym and hard links with rsync so like... yeah
< luke-jr>
phantomcircuit: depends on client configuration in theory
< luke-jr>
and that's expected behaviour at least
< phantomcircuit>
luke-jr, iirc the flags just control what the client requests
< wumpus>
sipa: it kind of confuses me, according to the test it's supposed to generate bit patterns in j with i bits set
< luke-jr>
phantomcircuit: ugh
< phantomcircuit>
luke-jr, tons of stuff works that way
< luke-jr>
wumpus: actually, looking at that further looks .. dumb
< * luke-jr>
wonders wtf that's *trying* to do
< luke-jr>
for (unsigned j = 1U << (i - 1); (j >> i) == 0; ++j) {
< wumpus>
that creates an 'unsigned int' which is probably 32 bit, won't the shift potentially shift out of the register or even create undefined behavior
< luke-jr>
wumpus: unsigned int is guaranteed to be at least 16-bit, and this is only done when i is <10
< wumpus>
hhmm okay
< wumpus>
I... don't think adding that reliance is very nice
< luke-jr>
it's gotta rely on some bit width regardless. no reason to do 64-bit when we know it won't be 64-bit :p
< wumpus>
the input to that bitcounting function is 64-bit, and it's a test for that, so limiting it at that makes some sense
< luke-jr>
and if the standards-required assumption of 16-bit ever fails, the test will just fail
< luke-jr>
which we probably want anyway, considering other code currently assumes it's 32-bit :p
< wumpus>
true; I wish C++ had 1u64 like rust
< sipa>
e could define a user-defined literal for it
< sipa>
c++11 feature :)
< wumpus>
interesting
< luke-jr>
sipa: ?
< wumpus>
nice feature, I don't think that's used anywhere in the code yet
< bitcoin-git>
bitcoin/master f411c8b João Barbosa: gui: Remove unused return type in some BitcoinGUI methods
< bitcoin-git>
bitcoin/master 8a79261 João Barbosa: gui: Keep network style in BitcoinGUI
< bitcoin-git>
bitcoin/master fe7048b João Barbosa: gui: Show current wallet name in window title
< bitcoin-git>
[bitcoin] jonasschnelli closed pull request #15149: gui: Show current wallet name in window title (master...2019-01-updatewindowtitle) https://github.com/bitcoin/bitcoin/pull/15149
< jamesob>
is there any good reason that ofstream objects can't be used as a stream with the serialize functions?
< sipa>
jamesob: i think it just diverged; they used to implement a similar interface, but nothing used stdlib stream objects, so changes over time broke the compatibility?
< sipa>
what causes it? the GetVersion etc?
< jamesob>
trying to figure that out atm but I don't think it's GetVersion; top line of the compiler barf is
< jamesob>
in the meantime I can do a CDataStream intermediary I guess
< gwillen>
heh, I just tried to do this the other day
< gwillen>
and assumed it was just not meant to work
< gwillen>
and wrote a little std::string returning wrapper around CDataStream nonsense instead
< jamesob>
ah funny. I'm dealing with binary and so want to avoid string
< luke-jr>
followup on the random_tests failure the other day, apparently some are seeing it with raii_tests instead: https://bugs.gentoo.org/675546 :/