< fanquake>
dongcarl thanks, I'll check out the capability tool today
< mischa010>
so is there any data on the average block verification time? preferably historical too?
< gmaxwell>
mischa010: your question is underspecified. What do you mean exactly?
< gmaxwell>
You were asking about propagation earlier-- so I might guess that your question is related to that? blocks essentially have no validation time in propagation 'on average'.
< mischa010>
well say it's before compact blocks and signature caches, nodes would get a block from another node and then verify it before propagating it, right?
< gmaxwell>
mischa010: signature caches were added in like 2012...
< mischa010>
oh hehe
< mischa010>
but there must be some delay
< mischa010>
before it's sent on to others?
< mischa010>
or was, before compact blocks
< gmaxwell>
Propagation has gotten faster through dozens of different changes in essentially every major version since 2012.
< gmaxwell>
So it's not easy to just give a x/y figure.
< mischa010>
to give some context: i made up a model to predict propagation times and it seems to agree with data quite well, but it contains a term for the 'propagation speed'
< gmaxwell>
Currently? my logs from a day ago show that of the 143 blocks it got, 6 contained any transactions it didn't know in advance. So in those cases some transactions needed to be validated. Otherwise none did, and the only time taken was the compact block reconstruction and verifying the hash.
< gmaxwell>
mischa010: what data? the bc.i data that I told you was essentially worthless? :P
< mischa010>
so it works if i set that to 4 mbit, but there's zero justification for that
< mischa010>
no the new data you gave me works too
< mischa010>
like 10% max relative error
< mischa010>
but again, only if i assume 4mbit propagation speed
< gmaxwell>
IIRC the slope of the line in that data is about 750kbit/sec.
< gmaxwell>
which is pretty reasonable for worldwide (high RTT) tcp.
< gmaxwell>
anything post compact blocks (or really even post relay network protocol) is mostly measuring the deployment level of compact blocks.
< gmaxwell>
since, as mentioned above, the overwhelming majority of blocks don't need to transfer any transactions at all at block time.
< mischa010>
yes
< mischa010>
well thanks
< mischa010>
back to the drawing board it is
< gmaxwell>
it's also really hard to measure performance in the network because the performance you get in the network is a composite of multiple different techniques.
< gmaxwell>
E.g. normally the vast majority of long haul block propagation is done by FIBRE, since it achieves hundreds of times TCP throughput over high latency links pretty easily...
< mischa010>
btw gmaxwell, y axis says '50% of pools', do you remember how many pools?
< gmaxwell>
BlueMatt: I think we should drop v1 HB mode support. There is no point in sending blocks quickly to v1 peers.
< fanquake>
sipa / wumpus can you block kevinschoen from GitHub
< fanquake>
They are spamming a link to a website that is very likely malware
< fanquake>
With an "official" looking URL.
< sipa>
fanquake: done
< fanquake>
sipa thanks.
< fanquake>
I have removed all of the comments.
< sipa>
fanquake: great
< echeveria>
fanquake: I can confirm that this is an attack site (as if it wasn't obvious). depending on the links you follow, you either get the legit binaries, or "bitcoin.exe".
< fanquake>
echeveria thanks
< gmaxwell>
I wonder if its the same parties that have been attacking electrum users?
< echeveria>
gmaxwell: using NameCheap is within the Electrum malware's style.
< gmaxwell>
Fun fact, 82% of my banlist IPs are from 10 ASNs.
< wumpus>
so apparently there's some funding initiative by Twitter/Square for core devs (I only learn of this through twitter now), https://twitter.com/jimmysong/status/1108500506106843137 - anyhow, if you're actively involved in Bitcoin Core's development and need this funding, and would like me to write a recommendation for you, let me know
< fanquake>
wumpus yea it looks interesting. Keen to see how the designer works with Qt & the project in general.
< gribble>
It just seems like what everyone else is doing.
< gmaxwell>
mischa010: actually here is a more complete log that also shows that it took 72ms to validate (hot cache). https://0bin.net/paste/-tXEltim85EBuCfv#84o+e5Uxv5IYu9LsQ-fLpBtog877N1PI5QsRCFpoRco
< bitcoin-git>
[bitcoin] gmaxwell opened pull request #15633: Ignore BIP-152 HB requests from non-witness peers. (master...201803-nohbcbfornonwit) https://github.com/bitcoin/bitcoin/pull/15633
< jonasschnelli>
Is or should it be possible to reduce the dbcache size once the node has completed IBD,... without a restart?
< jonasschnelli>
I guess if I run with a large DB cache and the node has done IBD a couple of hours ago, it will not write the state to the database expect hitting the cache (or a shutdown)?
< jonasschnelli>
There is AFAIK no time constraint that makes the cache write to disk... (hopefully I'm wrong)
< jonasschnelli>
*expect hitting the cache limit (or a shutdown)
< wumpus>
jonasschnelli: I remember there was some PR recently that added a flush of the dbcache immediately after IBD
< jonasschnelli>
wumpus: but that would still lead to consuming a lot of RAM over time (without significant performance benefits in most cases)?
< wumpus>
well yes the dbcache would fill again after that, it's mostly to prevent loss of data
< wumpus>
but don't underestimate, the cache still has 'significant performance benefits' for verifying incoming blocks/transactions
< wumpus>
even after IBD
< wumpus>
especially for miners (desire for as-fast-as-possible verification), or low-end hardware (slow i/o), this can be important
< jonasschnelli>
I'm currently targeting low-end hardware (aarch64) where RAM is crucial and find a good balance between fast sync (where other stuff may be disabled due to RAM constraints).
< jonasschnelli>
And once IBD has been done, switch to a lower dbcache to allow other processes to run seems desirable
< jonasschnelli>
And since its using SSD, i/o is non-crucial IMO
< wumpus>
if you have the database on a (real) SSD it is, but lots of ARM devices use either slow external HDD or some SD card
< wumpus>
anyhow, could be a configuration option I guess
< jonasschnelli>
wumpus: the Rock64pro has a PCI-e (m.2 NVME SSD) (for ~60USD)
< wumpus>
:o
< emilr>
not that much of an inconvenience restarting bitcoind after IBD, all this features create a lot of complexity and maintenance down the road
< emilr>
I'm building bitcoin on a rpi, biggest hurdle thus far is the dependency tree, I had to give up on building boost-libs and use binaries
< wumpus>
emilr: generally agree that trying to regulate things like this automatically results in an unpredictable mess
< wumpus>
but, like, an RPC that allows changing settings such as dbcache at runtime wouldn't be that bad
< wumpus>
(I think that'd be just a matter of flushing the current cache if it's > newsize and setting the new bound)
< wumpus>
the depends build should work on rpi
< wumpus>
(which will build boost, and optionally berkeleydb/qt/etc for you)
< wumpus>
I think it's one of the most popular devices to run a bitcoin node on
< emilr>
not sure it will work without a restart given linux's memory management, I'm building it on freebsd from ports atm
< wumpus>
linux's memory management is *definitely* able to give back freed memory to the OS, though things such as memory fragmentation can get in the way of course
< BlueMatt>
<gmaxwell> BlueMatt: I think we should drop v1 HB mode support. There is no point in sending blocks quickly to v1 peers. <-- ack
< BlueMatt>
seems like more than enough time has passed for that
< gleb>
Is core meeting in 10 minutes?
< wumpus>
should be in 45 minutes
< gleb>
I see, thanks.
< wumpus>
it's 19:00 Reijkjavik time (UTC)
< phantomcircuit>
wumpus, flushing the cache after ibd seems like a bad idea, that would vastly increase the latency of procssing blocks in the future
< phantomcircuit>
processing*
< jamesob>
I still don't get why we necessarily empty the cache upon flush
< wumpus>
phantomcircuit: it has some drawbacks as well, sure
< wumpus>
jamesob: because there's that's the only eviction policy
< wumpus>
cache is full → evict all, I remember some experiments were done with other ideas, but it didn't improve performance while it did make the code much more complex
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Mar 21 19:00:15 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< gribble>
https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
< provoostenator>
I'll take a look at both
< wumpus>
what is the different between the approaches?
< jonasschnelli>
gmaxwell wanted to revert the PR that causes the issue (GUI load/unload)... though I think #15313 is fine
< jonasschnelli>
The #15614 fix delays the unload until all modal windows haven been closed
< gribble>
https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
< jonasschnelli>
where #15313 does close them directly
< luke-jr>
jonasschnelli: I get that, I just don't understand how #15614 works
< wumpus>
ok I'll contingently tag 15313 for 0.18.0 then
< gribble>
https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
< promag>
luke-jr: the issue comes from QDialog::exec, which spins another event loop
< jonasschnelli>
15313 will just wait until user closes it, which can lead to a timeout in RPC unloadwallet (probably okay)
< wumpus>
oh, was already tagged
< jonasschnelli>
Sry,... wrong. I meant 15614 is the one that waits
< jonasschnelli>
15313 does close it explicit and then unload the wallet
< jonasschnelli>
but not all dialogs can be closed with the current code (needs major refactoring)
< jonasschnelli>
lets just go with 15614...
< promag>
yap, I've started it but its too much for 0.18
< jonasschnelli>
yes
< luke-jr>
ok, I think I see how it works basically
< wumpus>
that's not really an option for 0.18.0, no, then I'd prefer the revert approach
< promag>
luke-jr: 15614 delays the wallet model destruction after all dialogs are closed
< luke-jr>
but does a focus change necessarily mean the GUI is done with it?
< luke-jr>
specifically, isn't coin control non-modal?
< jonasschnelli>
15614 is a good fix for a case where someone unloads a wallet via RPC when using the GUI (probably rar use-cases)
< promag>
luke-jr: afaik there is no signal to know the active window changed
< wumpus>
jonasschnelli: ok good to know
< jonasschnelli>
luke-jr: it just checks again... when the focus changes (since this is what happens if you close a Dialog)
< jonasschnelli>
The long term fix is avoiding synchronous calls
< promag>
jonasschnelli: luke-jr: actually now I remember there is QWindow::activeChanged since qt5
< promag>
I'll recheck
< jonasschnelli>
however, please review #15614 to merge it into 0.18 asap
< gribble>
https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
< jonasschnelli>
we probably won't ship with known and fixable crashes
< MarcoFalke>
#action review #15614
< gribble>
https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
< MarcoFalke>
Should also do a forward-port to master?
< MarcoFalke>
Or maybe open the pull against master?
< promag>
MarcoFalke: I'll rather not, unless you prefer, cause the right fix is to remove qdialog::exec calls
< jonasschnelli>
promag: regardless of the long term solution, we probably want this also in master
< promag>
no strong opinion really
< luke-jr>
things are supposed to go into master before backports (although I can think of cases where that's not viable, so maybe it should be a hard rule)
< jonasschnelli>
what luke-jr says
< promag>
MarcoFalke: I'll push it then
< luke-jr>
shouldn't*
< wumpus>
jonasschnelli: our usual strategy is to have everything in master first, so that no fixes get lost
< MarcoFalke>
jup, agree with luke-jr
< promag>
ok np
< jonasschnelli>
wumpus: yes.
< wumpus>
if something *only* applies to a branch there's of course an exception
< wumpus>
butthat's not the case here
< promag>
just note that it will be reverted
< wumpus>
not reverted, replaced
< promag>
right :)
< luke-jr>
*shrug* reverts are fine when appropriate
< wumpus>
reverts are fine if some change turns out to be bad
< wumpus>
we could to that too …
< wumpus>
that was gmaxwell's proposal right
< wumpus>
though if other changes built on top since, it might be non-trivial now
< promag>
reverting that brings other issues
< luke-jr>
wumpus: we're talking about a revert of the bandaid fix
< luke-jr>
eg, as part of a real fix
< wumpus>
I think we shouldn't have merged those things so late, in retrspect
< promag>
again, this is really very unlikely, you have to run bitcoin-qt -server
< luke-jr>
would be nice to get getbalance fixed, but I need to run.. <.<
< wumpus>
#topic win codesigning cert (cfields)
< cfields>
I'm still trying to understand what's going on, but it seems as though the win cert has expired
< wumpus>
oh?!?
< jonasschnelli>
oh..
< cfields>
But afacs it's not causing any problems.
< cfields>
So I'm confused.
< jonasschnelli>
cfields: should we register a new one via the Bitcoin Core Code Signing Association?
< cfields>
I always do a test-install on Win7, and the cert should've been expired for rc2, but nothing complained.
< jonasschnelli>
cfields: tolerance period? :-)
< cfields>
jonasschnelli: I think yes, asap if possible.
< jonasschnelli>
cfields: I have never done this. Glad if someone with Win experience wants to do it. I'm ready to support on the legal/address/payment side.
< cfields>
jonasschnelli: If you're up for that, I'm happy to help.
< jonasschnelli>
Okay. Lets do that together cfields.
< cfields>
I haven't either, but I think I have a few records from the last cert.
< cfields>
jonasschnelli: Thanks!
< wumpus>
awesome, thanks jonasschnelli and cfields
< cfields>
sorry if this causes problems..
< wumpus>
without you we'd probably have to drop windows support :)
< jonasschnelli>
Would also be good to get a sponsor for the Bitcoin Core Code Signing Association at some point (raise your hand if your willing)
< cfields>
wumpus: maybe we should discuss an async win release?
< cfields>
wumpus: Hah, in that case I'll leave!
< wumpus>
cfields: how do you mean?
< cfields>
async win release just in case, that is.
< gwillen>
jonasschnelli: sponsor in what sense?
< cfields>
If there's a cert problem that would delay the win release, it'd be a shame to hold up everything.
< jonasschnelli>
gwillen: There are litte costs (domain, macOS developer programm and now the win code signing cert)
< cfields>
heh, I realize this is like the 10th time now that I've suggested that :)
< wumpus>
you mean doing a release without windows binaries?
< wumpus>
I… don't think I want to do that
< wumpus>
will get too many complaints
< cfields>
wumpus: ok, no worries, just thinking of contingencies.
< luke-jr>
jonasschnelli: I would prefer to see someone sponsor a neutral codesigning org
< gwillen>
jonasschnelli: I am happy to pay little costs, I would assume there are plenty of people here willing but lmk
< jonasschnelli>
Indeed. Also, watch out, this is a discussion rabbit hole (windows yes/no)
< wumpus>
cfields: for an RC it's okay, I think
< wumpus>
cfields: but not for final
< cfields>
I would be curious to know if rc2 is busted on win10, though.
< cfields>
If it is and nobody noticed, that'd be noteworthy.
< wumpus>
I don't think it is
< wumpus>
someone would have told me
< jonasschnelli>
I'll do some VM testing asap
< cfields>
thanks all. </topic>
< jonasschnelli>
gwillen: great to hear.. just need to find a good way how to do this
< wumpus>
any other topics ?
< jnewbery>
We didn't talk about high priority for review, but I guess high priority isn't high priority when we have an upcoming release
< sipa>
yeah
< jnewbery>
My only suggestion would be to add #14121 to the list, which has a few ACKs and seems close to being mergeable
< wumpus>
jnewbery: and right, we skipped high priority review just before the branch / rc1 release, but now that that is done, I suppose enough people are focusing on things to get into 0.19.0 already
< gwillen>
luke-jr: I'm happy to pay minor costs either way but who outside core would use it?
< cfields>
woohoo!
< promag>
MarcoFalke: didn't know you could change base!
< jonasschnelli>
me neither
< sipa>
change base?
< jonasschnelli>
switch a PR from 0.18 to master (as exampe)
< kanzure>
mailing list update: migration still pending. linuxfoundation is in charge of this, and i don't get updates from them.
< kanzure>
warren might have more info
< jonasschnelli>
kanzure: thanks for the update
< kanzure>
sorry it's not more helpful :)
< jonasschnelli>
Maybe also write back that that email asking why it was so short notice
< wumpus>
yes, he mentioned it, it's been delayed a bit
< warren>
I'm writing a longer story of what led up to this for the list, and we have another delay due to one guy taking sick leave.
< kanzure>
i suppose the reason for short notice is that we didn't inform everyone a year ago when linuxfoundation announced their intentions
< kanzure>
although i do vaguely recall talking about it
< jonasschnelli>
Yes. But the list doesn't know that
< jonasschnelli>
Or I missed it
< warren>
Late 2017 they notified us that mailman2 was unmaintainable and they had to eventually migrate all their lists onto a new platform. mailman2 had a dead upstream for years and mailman3 they tried but determined was unusable. <then a long story of evaluating options follows>
< warren>
<then how predictably people will try to step up to claim they can self-host it>
< warren>
This is a long story and the list deserves to hear everything that happened and was considered.
< wumpus>
yes, I remember that
< wumpus>
it's increasingly difficult to do mailing lists, no one really cares anymore
< jonasschnelli>
which is sad
< wumpus>
(maybe except for the linux mailing list and freedesktop/mesa, everyone hates using them, let alone maintaining them)
< warren>
<I did try to ping many of you over the past year for opinions, got very little, then one of you blamed me for not just forcing a decision, I did one more round of asking many of you for opinions, most of you replied you don't care, we considered self-hosting options evaluated by aj, settled on the least effort solution with self-hosted archives> will explain all this on list.
< kanzure>
alright alright, no need to assign blame
< wumpus>
it's no one's responsibility so also no one's blame
< warren>
The guy who blamed me was right. It was unrealstic of me to expect "the group" could make a decision when most people don't care, they just want it to work.
< wumpus>
in principle it's even off topic in the bitcoin core meeting, the bitcoin-dev mailing list is outside it's scope, not that I mind
< jonasschnelli>
Yes. It's not managed by the Core team
< wumpus>
anyhow, I think we had this, any other topics?
< wumpus>
right
< warren>
right
< wumpus>
don't ask who it should be managed by, but it's not core's thing
< wumpus>
anyone who does care about the list should be happy that warren is doing this work at all, if not, it would just disappear
< jnewbery>
^ agree. Thanks warren!
< warren>
It's worth noting despite trying to deprecate the old mailman2 server they've tried to keep it online for us and a few other dev communities who had a hard time moving, and most of their downtime trouble was due to DoS attacks targeting only bitcoin-dev.
< jonasschnelli>
*sigh*
< warren>
The new infrastructure they recommend they are not concerned about DoS attacks, it's expected and better maintained so it won't fall over so easily.
< wumpus>
thanks to the Linux Foundation too, then! it wouldn't be crazy for them to drop bitcoin-dev if it's such a hot potato
< wumpus>
going to end this meeting, I don't think there's any more topics
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Mar 21 19:48:58 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< cfields>
jonasschnelli: Arrgh, I see what happened. I checked a few weeks ago to see when the cert would expire, and it's March 5 2019. But for whatever reason it was displayed in european order as 5/3/2019, so I thought we had time.
< warren>
I was afraid they would want to drop us because of these attacks but they see us as potentially important one day. Currently they don't understand us but "they stole some top kernel engineers ... might be important"
< wumpus>
surprisingly much of the infrastructure and stuff around bitcoin is hanging together by a few threads, and single individuals that happily still care about it
< cfields>
And maybe the signature only worked because we use osslsigncode rather than the official tool.
< cfields>
That still doesn't explain why the installer worked, though.
< jonasschnelli>
cfields: heh. No worries. Just tell me where to buy a new one (if you know that)
< warren>
oh I missed the win signature discussion, will it be something other than Bitcoin Foundation in the future?
< jonasschnelli>
gwillen eventually sponsors the cert (well,.. he doesn't know the costs yet)
< jonasschnelli>
warren: yes
< cfields>
jonasschnelli: I'll look up the old stuff and forward it to you. Gavin forwarded the previous registration stuff to me I think.
< jonasschnelli>
Bitcoin Core Code Signing Association (based in Switzerland)
< jonasschnelli>
(same as for macOS since a while)
< jnewbery>
cfields: 'european order' lol
< gwillen>
yes I am happy to formally donate to the Bitcoin Core Code Signing Association, someone should tell me an amount and where to mail a check :-)
< jonasschnelli>
a check he said
< gwillen>
;-)
< cfields>
jnewbery: Lol, wow. Can't believe it came out that way.
< jonasschnelli>
Well... if someone questions the existence of the association... I haven had to get a D.U.N.S. number to walk though the apple process
< cfields>
Ah, heh. Makes sense.
< jonasschnelli>
cfields: Please provide gwillen your email address,.. so only you can then create / manage the certificate
< jonasschnelli>
(he will buy it... if that works)
< jonasschnelli>
I need to cut costs on my side,.. since Bitmain is in troubles
< warren>
jonasschnelli: what is the structure of the association? surely we should spread these costs out to many members? how is the association chartered? I had been exploring with the Linux Foundation ways to charter non-profits in ways where funders are unable to interfere with the mission of an org for readingbitcoin.org
< jonasschnelli>
warren: there is no real structure. :/ It has just been setup with minimal paperwork to get the certificates
< jonasschnelli>
I think its probably not worth to do it...
< jonasschnelli>
There is another association I'm currently building up (with a proper structure) called "Bitcoin Developer and Researcher Association" (BitDRA) which should aim to finance real work/projects
< warren>
I think people have rightly been fearful of central orgs paying for developers, but we're increasingly seeing multiple orgs both for-profit and non-profit. Some common safety driven peer-review driven process between many contributing orgs seems to be de facto how this can work without creating new risks.
< gmaxwell>
please thats unrelated to the signing thing. the signing thing should be single purpose and isolated.
< jonasschnelli>
Yes. Indeed
< warren>
I didn't suggest they be related.
< luke-jr>
jonasschnelli: what makes little sense is Core-only. what good is it to pay the same costs more than once for no benefit?
< luke-jr>
gwillen: Knots at least; I would think HWI stuff also, and probably Lightning wallets
< jonasschnelli>
luke-jr: I see that point. Its just about risks, affiliation and key management
< jonasschnelli>
Which is not worth for the costs of 200$/year
< jonasschnelli>
(not worth to mix IMO)
< cfields>
gmaxwell: see above about the threshold stuff. Any reason to hold off a day or two for something better than a single signer?
< gmaxwell>
I've got nothing there. Sorry.
< cfields>
Ok, np.
< luke-jr>
jonasschnelli: what risks/affiliation?
< warren>
luke-jr: it's hard enough to be responsible for one publication, if it costs $200/yr you're better off creating another org get to another key.
< jonasschnelli>
luke-jr: Assume Core goes rouge, or Knots, ... or the key gets compromised by one of the ends
< luke-jr>
warren: plus time to research how to set it all up; once set up, signing multiple things doesn't really add difficulty
< jonasschnelli>
luke-jr: well,... you could end up with a signing malicious binaries that tears down the other organisation (not technically)
< luke-jr>
jonasschnelli: obviously there would have to be some reasonable policy on what gets signed (eg, gitian builds of Bitcoin-compatible software)
< warren>
luke-jr: it's problematic that this signature essentially leads to users blindliy trusting it as almost nobody verifies gitian builds actually match up.
< luke-jr>
warren: that's a problem regardless :/
< luke-jr>
and if anything, signing more things would *reduce* that
< sipa>
what is the signatures provided by this org supposed to assert?
< sipa>
"this binary is the gitian build of this git commit"?
< sipa>
or "this is bitcoin core"
< luke-jr>
"this binary is the gitian build of this git commit" sounds reasonable, if even that
< gwillen>
"the bitcoin core code signing association thinks Windows should not yell when running this binary"
< luke-jr>
"this is bitcoin core" *should* be meaningless really
< jonasschnelli>
sipa: its just hocus pocus
< luke-jr>
gwillen: pretty much :P
< gwillen>
the problem is that you will get your cert revoked if something goes bad with a binary you sign
< luke-jr>
sipa: the problem is certain DRM-laden OSs seem to be moving more and more toward a permissioned model
< warren>
although if that signature can't be threshold then it's really "this centralized signing association seems to have verified the gitian reproducibility of this binary and has enabled you to blindly trust this signing key"
< sipa>
luke-jr: if it is meaningless, the concept of code signing is meaningless unfortunately
< jonasschnelli>
It only tells users it was signed by an organisation called "Bitcoin Core Code Signing Association"
< jonasschnelli>
Its only for UX (in macOS you can't start unsigned applications by default)
< luke-jr>
sipa: it's to get into walled gardens
< jonasschnelli>
IMO it provides near to 0 security
< luke-jr>
gwillen: I would expect "goes bad" to have to be malicious?
< jonasschnelli>
(An attacker could register "Bitcoin Core Code Shitting Association" and signing the malicious binary with that and nobody would recognise that)
< gwillen>
I'm not sure what kind of problem it would take to get a cert revoked
< jonasschnelli>
The only security is probably that one needs to pay for the cert... :)
< warren>
The best we can do is 1) have orgs like this sign 2) have separate orgs verify the reproducibility of what is claimed to be signed and to sound off alarms if it doesn't match 3) peer-review process hopefully prevents malicious code from getting to publication
< cfields>
sipa: I've always assumed your first definition. I've also been careful to never publish a full signed binary, only the detached part of the binary that _I built_. So it's useless unless reproducible.
< cfields>
*detached sig for the binary
< gmaxwell>
gwillen: they don't even revoke stuff that is signing malware. I think the only way to get a cert revoked is to directly piss off an executive at the related companies.
< luke-jr>
lol >_<
< warren>
Windows browsers, at least Microsoft Edge and Chrome seem to rely on centralized lookup of binary hashes. Known malicious binaries are flagged. If a binary is too new to be known by those lookup services then the browser warns the user. It seems they use this instead of certificate revocation.
< warren>
(also yikes, who has access to the server seeing all the lookups?)
< sipa>
cfields: so i think if all the signature itls intendes to convey is a correct build from some source code, it isn't really usable as codesigning thing for win/osx applications
< cfields>
sipa: "isn't really usable" meaning it's not working as would be expected to users?
< sipa>
cfields: there would at least be some implied understanding that the cert asserts the source code comes from a reliable repository with review practices
< sipa>
or even that the source code is what people canonically understand to be bitcoin core
< cfields>
sipa: yes, agreed. It doesn't function that way at all.
< cfields>
Which will be pretty obvious when ~0 people notice that new releases are coming from a new developer cert :)
< warren>
3rd party verifiers checking and sounding alarms is the best we can do under current limitations
< sipa>
i don't know what the solution is... i can see the use of a "this just asserts the build was created correctly!" service, but it isn't what people (and microsoft/apple) would understand a codesigning cert to correspond to
< cfields>
We only codesign to make the stupid nag screens go away at install-time.
< gwillen>
I don't think microsoft/apple understand the cert to mean anything in particular
< gwillen>
it is really just a hoop to jump through so users will be permitted to run the binary
< warren>
plenty of windows software isn't signed now, while Apple a few years ago locked down the UX where the user had to jump through hoops to run unsigned binaries
< cfields>
sipa: agree that would be a neat service, independent of codesigning.
< cfields>
warren: that's the case in Windows too.
< sipa>
gwillen: i'm sure there is some sense of verifying that the binary was signed by the known developer of the software it claims
< gwillen>
there really isn't
< gwillen>
I mean, maybe some manager somewhere in the process has that mental model
< gwillen>
but the implementation sure doesn't care
< sipa>
haha
< gwillen>
you can get EV certs
< warren>
I didn't suggest a solution but I did mention above that Windows browsers already use a hash blacklist for known bad downloads. It sucks that we can't have additional checks in front of the signature but maybe we could add safeguards after.
< gwillen>
but the regular certs run just fine
< gwillen>
sipa: I just bought one of these using my own name and credit card and cfields' email address
< gwillen>
they didn't verify anything other than that my money was green
< sipa>
gwillen: say you're the developer of GwillenCalc, could I register as Glenn Willen from GwillenSoft and publish a backdoored version of GwillenCalc that way?
< gwillen>
yes, 100%
< gwillen>
at least as far as I can tell
< sipa>
interesting
< gwillen>
they are just like SSL certs
< gwillen>
except with no domain to bind to
< warren>
gwillen: windows cert, apple or both? The latter seems more strict?
< cfields>
sipa: To that point, in another life, we had to squat on our app's name months before the android port was complete and actually ready for the App Store.
< cfields>
I don't remember the details now, but I believe it was because there was very little in place to prevent what you're describing.
< gwillen>
I think apple is a little stricter
< gwillen>
you can only get an apple code signing cert directly from apple through your apple account, which they will presumably blacklist if you misuse it
< gwillen>
the windows one I just bought from Comodo, which should tell you everything you need to know
< luke-jr>
at the end of the day, if Jonas doesn't do a general codesigning thing, I'll probably need to eventually, and it would be nice to have the general one (whoever does it) sponsored :/
< cfields>
gwillen: Microsoft isn't the gatekeeper, it's decentralized.... to the 3(?) whitelisted CA's :p.
< echeveria>
wumpus: for the record, I reported the malicious versions of the bitcoin core website to the host.
< echeveria>
which sadly has a similar domain name.
< echeveria>
warren: it's a bloom filter.
< echeveria>
for things like google safebrowsing, which catches a lot of things like some of the electrum malware.
< warren>
echeveria: ahhh
< warren>
echeveria: it sucks when it flags non-malicious things as malicious, which sometimes happens
< echeveria>
safebrowsing in particular seems to have crappy review.
< echeveria>
it's totally random if a report with a binary analysis of malware ends up in the list or not.
< luke-jr>
warren: what sucks most, is that there's literally no way to appeal it