< bitcoin-git> [bitcoin] achow101 opened pull request #10563: Remove safe mode (master...rm-safemode) https://github.com/bitcoin/bitcoin/pull/10563
< bitcoin-git> [bitcoin] gmaxwell opened pull request #10564: Return early in IsBanned. (master...banned-early-term) https://github.com/bitcoin/bitcoin/pull/10564
< bitcoin-git> [bitcoin] achow101 opened pull request #10565: [coverage] Remove leveldb, univalue, and benchmarks from coverage report (master...lcov-remove-extra) https://github.com/bitcoin/bitcoin/pull/10565
< bitcoin-git> [bitcoin] practicalswift opened pull request #10566: Use the "domain name setup" image (previously unused) in the gitian docs (master...unreferenced-file) https://github.com/bitcoin/bitcoin/pull/10566
< jonasschnelli> wumpus: the recent mail sent to security@ seems phishy... haven't checked although.
< wumpus> yes, I'd be careful
< jonasschnelli> Indeed
< jonasschnelli> Such attacks (against developers) will rise IMO... good protection is really required now
< wumpus> yes, agreed, we all need to start using qubes asap :)
< timothy> the only problem of qubes is xen
< wumpus> right, that's kind of its central point of failure
< wumpus> its achilles heel. Then again, it does raise the difficulty and cost of compromise, which is the point of security
< timothy> people are moving to kvm, xen in less maintained (as "big players" only amazon uses it, but they don't push patches upstream)
< wumpus> that's good to hear - I use kvm a lot for manual VM wrangling
< wumpus> kvm+libvirt is a breeze to use
< wumpus> I also moved all gpg signing to tokens a while ago, as well as some critical ssh authenticions
< timothy> openstack is kvm-based :)
< timothy> ovirt / rhv (red hat virtualization) too
< wumpus> trying to reduce attack surface as well as the impact when compromise would happen
< wumpus> okay :)
< timothy> I mean, big players are working on it
< timothy> infact I think I'll convert my gitian setup to use kvm instead of virtualbox
< wumpus> I've also started to use freebsd and openbsd for some things, to diversify from just linux
< wumpus> gitian with virtualbox? didn't know anyone was actually using that, most use either lxc or kvm
< timothy> the "official" procedure wants to install the VM on virtualbox and then gitian inside the vm
< wumpus> right, okay, yes the outer VM doesn't really matter, using virtualbox there because it's easy to set up both on linux and windows
< timothy> my main OS is fedora, so it's not to easy to use gitian directly here :P
< wumpus> I'm imagine - never tried
< wumpus> I'd*
< MarcoFalke> hmm, I haven't had any major issues running gitian in fedora
< wumpus> also moving critical infrastructure to RiscV/open hardware as possible, as devices become available
< wumpus> MarcoFalke: might be useful to add that to one of the documents, apparently people think it only works on debian derivatives
< bitcoin-git> [bitcoin] practicalswift opened pull request #10568: Remove unnecessary forward class declarations in header files (master...fwd-decl) https://github.com/bitcoin/bitcoin/pull/10568
< bitcoin-git> [bitcoin] achow101 opened pull request #10569: Fix stopatheight (master...fix-stopatheight) https://github.com/bitcoin/bitcoin/pull/10569
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/29f80cd230c3...76f268b9bd1b
< bitcoin-git> bitcoin/master 90593ed practicalswift: Limit variable scope
< bitcoin-git> bitcoin/master 76f268b Pieter Wuille: Merge #10521: Limit variable scope...
< bitcoin-git> [bitcoin] sipa closed pull request #10521: Limit variable scope (master...tighten-scope) https://github.com/bitcoin/bitcoin/pull/10521
< gmaxwell> jonasschnelli: http://imgur.com/a/PxsfD post on reddit linking that, looks like a bug that it's showing unknown for a synced up node?
< gmaxwell> luke-jr: you should ping everyone listed on this https://en.bitcoin.it/wiki/Segwit_support 1:1 to make sure its accurate.
< luke-jr> gmaxwell: hmm, so I think the only ones who haven't edited or been pinged 1:1 so far would be: sdaftuar MarcoFalke maaku rusty petertodd
< luke-jr> does p2p-fullblocktest's runbarelyexpensive timeout for anyone else? it seems to have a limit of 60s for a 1000+ block reorg, which isn't practical? O.o