< bitcoin-git>
[bitcoin] pierreN opened pull request #18433: serialization: prevent int overflow for big Coin::nHeight (master...fix-coin-serialize) https://github.com/bitcoin/bitcoin/pull/18433
< bitcoin-git>
[bitcoin] fanquake opened pull request #18434: tests: add a test-security target and run it in CI (master...run_security_check_ci) https://github.com/bitcoin/bitcoin/pull/18434
< aj>
fjahr: you writing a test for wtxid relay already?
< bitcoin-git>
[bitcoin] hebasto opened pull request #18436: [WIP] [do not merge] ci: Fix brew in Travis (master...20200326-travis-brew) https://github.com/bitcoin/bitcoin/pull/18436
< hebasto>
fanquake: it seems #18436 fixes macos native build on travis, but not sure if this is the best approach: it reverts changes of previous bugfix
< fanquake>
hebasto: is whatever the previous bugfix fixed still relevant?
< hebasto>
not sure
< fanquake>
Might also be worth looking at using "update: true" and a package list in travis.yml rather than all the custom logic we seem to have to update homebrew.
< bitcoin-git>
[bitcoin] vasild opened pull request #18437: util: Detect posix_fallocate() instead of assuming (master...posix_fallocate) https://github.com/bitcoin/bitcoin/pull/18437
< bitcoin-git>
[bitcoin] hebasto opened pull request #18438: [WIP] ci: Use Homebrew addon on native macOS (master...20200326-brew-addon) https://github.com/bitcoin/bitcoin/pull/18438
< fanquake>
hebasto: can you close the original PR, or combine the new changes into it
< hebasto>
fanquake: sure, just after tests pass, if you don't mind
< fanquake>
sure
< hebasto>
fanquake: brew reports that libtool, boost, qt and python3 are skipping to install as they are up-to-date. Should we still explicitly tell Travis to install them?
< fanquake>
I don’t think that’s necessary. If they are up to date, and Travis is checks each run that should be fine.
< hebasto>
it seems we need make travis to log versions of the packages that are skipped by homebrew...
< hebasto>
fanquake: on macOS python's "zmq" and homebrew's "zmq" do the same things? or python package for tests only?
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #15704: Move Win32 defines to configure.ac to ensure they are globally defined (master...win32_defines_globally) https://github.com/bitcoin/bitcoin/pull/15704
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #15704: Move Win32 defines to configure.ac to ensure they are globally defined (master...win32_defines_globally) https://github.com/bitcoin/bitcoin/pull/15704
< bitcoin-git>
bitcoin/master d831831 Luke Dashjr: lockedpool: When possible, use madvise to avoid including sensitive inform...
< bitcoin-git>
bitcoin/master 23991ee Wladimir J. van der Laan: Merge #15600: lockedpool: When possible, use madvise to avoid including se...
< bitcoin-git>
[bitcoin] laanwj merged pull request #15600: lockedpool: When possible, use madvise to avoid including sensitive information in core dumps (master...lockedpool_dontdump) https://github.com/bitcoin/bitcoin/pull/15600
< wumpus>
luke-jr: I guess that *should* be true, though there are some changes in that PR (like build system) that might potentially affect other platforms a bit. No strong opinion on including it or not for 0.20 though, given that it gathers enough ACKs
< jonasschnelli>
The problem is, when we do notarize the macOS versions, it creates a tcp check connection with apples servers
< jonasschnelli>
Which is kinda a no-go IMO
< jonasschnelli>
So the question is, do we want to help newby users by not needing to right-click-open the app, but reduce pricavy, ... or focus on higher provacy
< jonasschnelli>
I personally think preserving privacy has the higher focus right now
< wumpus>
so it won't do the TCP check for notarization if it's not notarized?
< jonasschnelli>
Yes. It won't
< jonasschnelli>
(though you either have to right-click open the app or disable the security feature)
< wumpus>
I think I'd slightly prefer to err on the side of privacy then
< jonasschnelli>
I think it make sense to "deposit" the possibility to notarize until apple enforces it or users really demand it
< achow101>
I thought the notarization could be stapled which would prevent the phone home
< luke-jr>
I agree with wumpus
< jonasschnelli>
achow101: it still does
< jonasschnelli>
I tested it
< luke-jr>
achow101: apparently it still checks for revocations
< achow101>
that's a shame
< jonasschnelli>
achow101: With stapling, you can use it offline... but if you online, it still checks the validity
< luke-jr>
which isn't entirely unreasonable, but IMO should go over Tor if forced; but good luck convincing Apple
< hebasto>
could we maintain both versions?
< luke-jr>
hmm
< cfields>
Checking for revocations implies that it could be revoked by someone other than us. IMO that's reason enough.
< jonasschnelli>
We could... as long as the hashes are different...
< jonasschnelli>
but probably not worth it and will lead to more confusion
< luke-jr>
is there a benefit to having the signed-but-not-notarised variant at all?
< wumpus>
maintaining two versions sounds overkill to me
< wumpus>
it's not worth it for such a small thing
< luke-jr>
ie, can we just do unsigned and signed+notarised?
< jonasschnelli>
the "right-click-open" approach could be better communicated (release notes, or even in the DMG)
< luke-jr>
wumpus: we already have two versions really
< luke-jr>
jonasschnelli: it was in at least one rel notes, maybe restore that
< wumpus>
in general having mulitple choices for download confuses users
< jonasschnelli>
Best would be a note in the dmg.. but yeah. meh.
< luke-jr>
website could say right click thing too
< wumpus>
agreed
< wumpus>
mentioning it makes sense
< luke-jr>
ooh, how about having hte DMG background image say it?
< jonasschnelli>
yes. That.
< luke-jr>
if they right-click open in the DMG, does that fix single-click later after they copy?
< jonasschnelli>
Copy to /Application, 1. time start with "right click open"... (something like that in the .tiff)
< jonasschnelli>
luke-jr: very unlikely
< luke-jr>
jonasschnelli: does the signature do anything for us anymore?
< cfields>
don't you have to have the dmg already open to see the background? Implying that you've already right-clicked?
< jonasschnelli>
heh.. yeah. and that.
< luke-jr>
do they rightclick the DMG, or rightclick the app?
< jonasschnelli>
luke-jr: what do you mean with "signature do anything?"?
< luke-jr>
jonasschnelli: the point of the signature was to avoid a right-click, wasn't it?
< luke-jr>
if we need to right-click anyway, why sign?
< cfields>
luke-jr: I'm now wondering the same.
< luke-jr>
(Apple signature, I mean, obviously we still do a real gitian sig)
< cfields>
Does the right-click trick still work for completely unsigned apps?
< jonasschnelli>
Well... the apples idea is _not_ that signatures avoid right click. But yeah. With enforce notarization (10.14) we are back at the same problem.
< wumpus>
I'm not sure, they might start enforcing signing before enforcing notarization
< jonasschnelli>
cfields: good questions.
< cfields>
We should assume they'll eventually enforce everything they introduce.
< jonasschnelli>
All that stuff would be acceptable. If there would not be a mandatory call-apple connection that reveale the application-hash to apple.
< luke-jr>
cfields: AFAIK they still don't enforce signing strictly
< wumpus>
why *would* we stop signing? we already hve the flow for that anyhow
< luke-jr>
wumpus: it's an extra step; and it means we could stay with just 2 variants AND notarise
< wumpus>
I don't see any pressing reason to change that
< jonasschnelli>
indeed
< jonasschnelli>
Lets just see how Apple continues with notarization and have the stuff ready for a sitaution where we need it.
< jonasschnelli>
Maybe add a right-click info to the dmg/background
< luke-jr>
also, by stopping signing, maybe it will make it politically harder for Apple to enforce the notary? *shrug*
< wumpus>
yes, let's be prepared for when it is stricty enforced, that's likely to happen a tsome point
< luke-jr>
could be argued either way I suppose
< luke-jr>
but if there's no benefit to the signing, it's trivial to just not do it
< wumpus>
I'd prefer to not change it last minute for 0.20 at least, could reconsider for 0.21 if it makes sense, but dunno
< jonasschnelli>
Signing has benefits,... at almost no costs. Lets keep it.
< luke-jr>
jonasschnelli: what benefit?
< wumpus>
jonasschnelli: agreed
< wumpus>
any other topics?
< jonasschnelli>
luke-jr: users not verifiny gitian signaturs have a tiny proof of authicity.
< jonasschnelli>
/topic
< luke-jr>
jonasschnelli: if they don't verify gitian, why would they verify this?
< sipa>
hi!
< jonasschnelli>
luke-jr: the os does
< wumpus>
sipa: you're just in time for the end of the meeting it seems :)
< luke-jr>
jonasschnelli: when?
< wumpus>
(unless someone has a topic)
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Mar 26 19:31:16 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jonasschnelli>
luke-jr: an attacker would require to purchase a developer programm, identify himself, etc.
< luke-jr>
jonasschnelli: why would he?
< jonasschnelli>
luke-jr: users can right click info and see developer notes
< luke-jr>
but they don't..
< luke-jr>
those who might, would also verify the gitian sigs
< jonasschnelli>
luke-jr: even if they don't. With the default settings, they can be sure an attacked would had to identify with apple
< jonasschnelli>
*attacker
< luke-jr>
jonasschnelli: right-click opens it with or without a signature, thoug
< jonasschnelli>
luke-jr: I think so... :/
< jonasschnelli>
You kida right, if we recommend right-click open, we probably make the signature useless
< jonasschnelli>
(because they would also do the right-click open of a malicious clone)
< cfields>
Surely the app could also be revoked asynchronously, independent of launch-time.
< cfields>
After all, there's no way it refuses to run notorized apps without an internet connection.
< luke-jr>
cfields: it shows a warning dialog IIRC
< luke-jr>
cfields: and launch time isn't the concern as much as "this user is using <app>" is
< luke-jr>
annoyingly, this is entirely unavoidable with iOS/Android, so we may be losing eventually
< cfields>
luke-jr: right, I was implying that the runtime check isn't actually all that concerning, as we should assume it's happening in the background as well. So just _having_ Bitcoin Core could cause you to leak :\
< luke-jr>
cfields: the warning dialog IIRC basically says "it was good on <stapled notarisation date>, but might not be now"
< bitcoin-git>
[bitcoin] vasild opened pull request #18443: lockedpool: avoid sensitive data in core files (FreeBSD) (master...madvise) https://github.com/bitcoin/bitcoin/pull/18443
< bitcoin-git>
[bitcoin] luke-jr opened pull request #18444: Bugfix: RPC: Remove final comma for last entry of fixed-size arrays in RPCResult (master...bugfix_rr_arrfixed_comma) https://github.com/bitcoin/bitcoin/pull/18444
< bitcoin-git>
[bitcoin] practicalswift opened pull request #18445: tests: Add fuzzing harnesses for functions/classes in chain.h and protocol.h (master...fuzzers-misc-3) https://github.com/bitcoin/bitcoin/pull/18445