< bitcoin-git>
[bitcoin] luke-jr opened pull request #18133: Fix various edge case bugs in QValidatedLineEdit (master...bugfix_qvalidlineedit) https://github.com/bitcoin/bitcoin/pull/18133
< bitcoin-git>
[bitcoin] Empact opened pull request #18134: Replace std::to_string with locale-independent alternative (master...2020-02-to-string) https://github.com/bitcoin/bitcoin/pull/18134
< bitcoin-git>
[bitcoin] fanquake opened pull request #18135: build: add --no-insert-timestamp to Windows linker flags (master...no_insert_timestamp_ld) https://github.com/bitcoin/bitcoin/pull/18135
< wumpus>
it would definitely be nice to have a release note for asmap, noting that it's an experimental feature, what it does, a link to how to use it
< jonatack>
yes. will propose this weekend (separately from 17812 since it already has review and acks) if gleb doesn't do one before
< jonatack>
heh, only now realised that it's friday already
< jonatack>
err, thursday
< luke-jr>
would asmap be worth including in Knots 0.19.1 for some earlier testing? mostly I'd just need to get rid of the dummy binary file (patch doesn't like those)
< sipa>
i don't think we're planning on distributing the map file yet
< luke-jr>
sipa: last time I looked, the PR had a like ~30 byte binary file included?
< luke-jr>
I assume an empty asmap
< jonatack>
sipa: ETA? is review needed in sipa/asmap? fwiw i've been running an experimental node since weeks with sipa/asmap/demo.map (932999 bytes)
< sipa>
luke-jr: oh, that's for the testz
< sipa>
we have plenty of binary files for testing, no?
< luke-jr>
ah, I can probably just drop the test then
< luke-jr>
sipa: probably, but I distribute Knots in patch form, so I can't add binary files
< luke-jr>
keyword: add
< sipa>
ah
< sipa>
jonatack: ETA for what?
< jonatack>
sipa: distributing the map file. still, users may want to generate their own, i suppose?
< jonatack>
(this is unclear to me and i should look at that)
< * luke-jr>
wonders how much damage a malicious asmap could do
< sipa>
jonatack: i think the plan was to not have a distributed one in the first release
< vasild>
#17563 fixes a compilation error on FreeBSD (assuming -Werror). Right now I have to apply that fix on top of whatever other changes I have made in order to compile (I refuse to depart from -Werror). Would be nice to get some more reviews. It already has one ACK.
< dongcarl>
cfields_: Okay so is the codesigning done outside of gitian? And the gitian-win-signer.yml is just the signature attachment that's doable by everyone?
< cfields_>
dongcarl: IIRC it's to avoid having to change the gitian recipe for each release.
< cfields_>
Right
< wumpus>
yes, gitian-win-signer attached the signature and validates the result IIRC
< dongcarl>
I see, this is roughly the same for gitian-osx-signer as well?
< cfields_>
I take bitcoin-0.19.99-win-unsigned.tar.gz, untar it, run the script inside, and commit the results to bitcoin-detached-sigs
< cfields_>
Yup
< dongcarl>
(I'm implementing the functionality in guix right now that's why I'm asking)
< dongcarl>
cool, thanks!
< cfields_>
Ok. No need to emulate the name weirdness. Renaming to bitcoin-win-unsigned.tar.gz is just a hack.
< cfields_>
and same for osx.
< dongcarl>
roger that!
< cfields_>
#proposedmeetingtopic expiring Windows codesigning key
< kanzure>
#proposedmeetingtopic topic collection for physical meeting (follow-up)
< achow101>
dongcarl: #14325 changed the gitian-build.py script to use the versioned tarball instead of the generic one so that you could do concurrent release builds
< gribble>
https://github.com/bitcoin/bitcoin/issues/14325 | [gitian] use versioned unsigned tarballs instead of generically named ones by achow101 . Pull Request #14325 . bitcoin/bitcoin . GitHub
< dongcarl>
achow101: Ah. There are too many places to look for what gitian is actually doing... Thanks for the pointer
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Feb 13 19:00:50 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< wumpus>
achow101: why is that? (deciding to stack more PRs)
< moneyball>
i would very much welcome a tool that automates my process of downloading the log archive and grep'ing for proposed meeting topics!
< wumpus>
replaced 16528 with 18034
< achow101>
mostly just cleaning things up so descriptor wallets is slightly less painful to review
< achow101>
missed a few things during all of the wallet boxes stuff, including a glaring hole in the design itself that doesn't work with hardware wallets
< wumpus>
okay if it helps review that's good
< wumpus>
whoops
< wumpus>
#topic Expiring windows codesigning key (cfields_)
< cfields_>
For once we're not scrambling to deal with an expired codesigning cert. The current Windows cert expires on Mar 26, 23:59:59 2020 GMT. We'll need to renew before then.
< cfields_>
Last year gwillen was kind enough to renew the cert for us.
< cfields_>
Also, it probably makes sense for the signer to be someone more active.
< wumpus>
any volunteers? what's involved?
< achow101>
does it require a windows machine?
< jonasschnelli>
We could purchase it via the Bitcoin Core Code Signing Association
< wumpus>
jonasschnelli: was about to suggest that
< jonasschnelli>
(make sure the certificate belong to that name)
< cfields_>
No, Windows isn't required. You hold a key and run a bash script for each release.
< jonasschnelli>
there are no funds though,.. :)
< jonatack>
how often does the cert expire?
< cfields_>
Since it's not a rush this time, I can open a github issue to discuss.
< wumpus>
how expensive is a cert?
< cfields_>
jonatack: This one was a 1year, I think you can also buy a 2.
< jonasschnelli>
Last time I checked most cert where around 200usd
< cfields_>
wumpus: good question, sec.
< jonasschnelli>
(per year)
< jonasschnelli>
always depends on the issuer...
< wumpus>
I guess we can't use the travel fund for this?
< jonasschnelli>
we could... or we find a generous sponsor. :)
< achow101>
I could do the signing. I've done every gitian build for quite a while, usually on time
< jonasschnelli>
I sponsor the apple one already,...
< jonasschnelli>
ack on achow101
< jonasschnelli>
(thanks for volunteering)
< wumpus>
sounds good to me!
< cfields_>
Yeah, I can't find the price off-hand, but it was somewhere under $200. IIRC closer to $100 for the 1yr.
< jonasschnelli>
I guess its best if you achow101 purchase the cert.. we can pay it via the coredev.tech fund if no-one opposes that
< wumpus>
+1
< wumpus>
but sure, if we can find another sponsor that'd be great
< jnewbery>
incidentally, thank you to everyone who replied to the survey (30 responses so far). Very much appreciate your time. I'll present aggregate results at coredev
< jonasschnelli>
macOS notarization is also done now. We start with the next release
< wumpus>
nice!
< cfields_>
would there still be interest in a multi-signer protocol for codesigning? That might be a good project for a student around here.
< cfields_>
Not for this time around, ofc. But maybe for next time.
< jonasschnelli>
I question if it is worth the effort... but if someone is up for... yeah. Why not
< jonasschnelli>
Just expect that Apple changes the key types (and enforces them) probably with 1 week notice.. :)
< cfields_>
Heh, fair point.
< jonasschnelli>
I guess its still RSA right now... but I'm sure they have plans to migrate away from that
< achow101>
cfields_: hasn't that been on the todo list for the past 6 or so years?
< jonasschnelli>
heh.. maybe past 4
< cfields_>
achow101: heh, yep, every time codesigning comes up. But this time I might actually be able to sucker someone into doing it :)
< wumpus>
it's a pretty old idea by now, yes, the problem is backfitting something like that into proprietary codesigning systems
< jonasschnelli>
And at the end, it's little security/trust compared to our gitian signatures
< wumpus>
right, it's not as if it's going to replace gitian signature verification
< cfields_>
Ok, not much interest.
< jonasschnelli>
I would rather invest resources in having a release-checker within bitcoin-cores binary (+Qt)
< cfields_>
Thanks, that's a helpful answer too.
< jonasschnelli>
Gitian is such a nice process.... but I doubt many people verify (which makes it kinda pointless).
< jonasschnelli>
If they could just verify from directly withing older bitcoin core versions.
< wumpus>
well at least the people that build verify that's something...
< jonasschnelli>
yes. that alone is a big plus.
< cfields_>
Yeah, I see it more as a proof that it can be done.
< cfields_>
Anyway, </topic>. Thanks.
< wumpus>
but yes it might be nice to have a tool that automates verification integrated, so that if people have one version of bitcoin core they can verify a newer one they downloaded
< jonasschnelli>
not that its not a cool project.
< jonasschnelli>
wumpus: Yes. Agree. We could have secp256k1 signatures from the gitian assert files... then verify those within core
< wumpus>
yup
< wumpus>
any other topics?
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Feb 13 19:39:42 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)