19:00:06 <achow101> #startmeeting 
19:00:18 <kanzure> hi
19:00:18 <achow101> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard aureleoules b10c BlueMatt brunoerg cfields darosior dergoegge dongcarl fanquake fjahr furszy gleb glozow hebasto instagibbs jamesob jarolrod jonatack josibake kallewoof kanzure kouloumos kvaciral laanwj LarryRuane lightlike luke-jr MacroFake Murch phantomcircuit pinheadmz promag provoostenator ryanofsky sdaftuar S3RK stickies-v sipa theStack vasild
19:00:37 <brunoerg> hi
19:00:42 <hebasto> hi
19:00:43 <Murch> Hi
19:00:44 <achow101> There are 2 preproposed meeting topics this week. does anyone have any last minute topics to add?
19:00:45 <furszy> hi
19:01:04 <pinheadmz> hi
19:01:12 <willcl_ark> hi
19:01:18 <jonatack> hi
19:01:23 <achow101> let's start with the usual
19:01:29 <achow101> #topic high priority for review
19:01:37 <achow101> anything to add/remove/merge? https://github.com/orgs/bitcoin/projects/1
19:02:05 <pinheadmz> #27101 can be removed, concept is ACKed, waiting for review
19:02:06 <gribble> https://github.com/bitcoin/bitcoin/issues/27101 | Support JSON-RPC 2.0 when requested by client by pinheadmz · Pull Request #27101 · bitcoin/bitcoin · GitHub
19:02:35 <achow101> pinheadmz: do you want to move it to blockers?
19:02:54 <pinheadmz> i thought blockers are for PRs that are blocking other PRs?
19:03:11 <achow101> blockers are for things that are blocking your work
19:03:36 <pinheadmz> theres no follow ups to that, so no.
19:03:46 <achow101> including the "final" pr
19:03:57 <achow101> it's just generally the actual high priority for review list
19:04:45 <pinheadmz> ok then!
19:04:55 <pinheadmz> #27039 is also ready for review
19:04:59 <gribble> https://github.com/bitcoin/bitcoin/issues/27039 | blockstorage: do not flush block to disk if it is already there by pinheadmz · Pull Request #27039 · bitcoin/bitcoin · GitHub
19:05:42 <achow101> you only get one on blockers
19:05:48 <pinheadmz> hahaha ok
19:05:58 <pinheadmz> blockstore then plz & ty ;-)
19:06:08 <achow101> done
19:06:32 <achow101> anything else to add?
19:07:32 <darosior> hi
19:08:02 <achow101> #topic host website using GitHub pages or similar (achow101)
19:08:50 <achow101> currently the website is hosted on a server administrated by someone who is no longer really involved in the project, and it occasionally stops working, requiring us to pester that person to fix it
19:09:04 <jamesob> hi
19:09:23 <achow101> since the site is basically just static pages, I think it would make sense for us to move its hosting to a static site host
19:09:28 <achow101> one such possibility is github pages
19:09:37 <achow101> any thoughts on this?
19:10:27 <hebasto> content is static mostly, right?
19:10:29 <jamesob> (for high-prio) I guess #24008 would be my request (now that the au.complete PR has been merged, thanks to all involved)
19:10:31 <jonatack> Just to be sure, this site? https://bitcoincore.org
19:10:32 <gribble> https://github.com/bitcoin/bitcoin/issues/24008 | assumeutxo: net_processing changes by jamesob · Pull Request #24008 · bitcoin/bitcoin · GitHub
19:10:56 <achow101> jamesob: added
19:10:57 <achow101> jonatack: yes
19:11:02 <jamesob> achow101: thanks
19:11:34 <pinheadmz> is the site being hosted in a certain country or on certain equipment or anything special like that for any reason?
19:11:42 <lightlike> if there are good alternatives, maybe it might makes sense to prefer one of those, so that if github should ever decide to kill the repo, at least the website would still be functional?
19:11:46 <jamesob> so the risk, IIUC, of having Github host that is that that site hosts sensitive files like expected binary checksums. But I guess the alternative risk is that we have to sort of trust whoever else would be hosting that site. And those files should be checked against signatures anyway
19:12:13 <achow101> pinheadmz: not that I'm aware of
19:12:22 <willcl_ark> I did come across an issue related to SigStore recently which, if we moved to a more GitHub-based release process, could be worth integrating now that SigStore is up and running? https://github.com/bitcoin/bitcoin/issues/21524
19:12:31 <willcl_ark> (to kind of act as a checksum against whatever is being hosted by GH)
19:12:39 <willcl_ark> a cross reference, sorry
19:13:17 <achow101> jamesob: but those are protected by signatures, so I don't think it particularly matters?
19:13:43 <jamesob> I wonder if we could segment the general information on that site away from the even-maybe-sensitive file hosting; the former being easily hosted on GH
19:13:59 <jamesob> Although maybe-sensitive stuff might be subtle, e.g. hyperlinks to download certain files
19:14:16 <jamesob> but yeah in general achow101 I agree, everything should be checked against signatures anyway
19:14:21 <achow101> I think that would be trivial by having a subdomain for the binaries
19:14:48 <jamesob> yup
19:15:05 <pinheadmz> where would we host the binaries?
19:15:35 <jamesob> inscriptions ;)
19:15:36 <jamesob> jkjk
19:15:40 <achow101> that leads into the second (part of the) topic where I'm wondering whether we could switch to hosting the binaries on github itself?
19:15:52 <achow101> since there is a releases page where release binaries can be uploaded
19:16:11 <kanzure> having users trained to download and verify from another source might be better than hosting both code and releases on the same system
19:16:14 <jamesob> I guess that seems as good a place as any; we could also encourage people to use torrents
19:16:31 <achow101> the issue with release binaries currently is that only a few people can upload the binaries, and none of them are the current maintainers
19:17:34 <achow101> lightlike: I think there are decent alternatives, but github pages is definitely the lowest barrier to entry
19:17:52 <sdaftuar> achow101: can we give some of the current maintainers access to upload binaries to the current site?
19:17:55 <jamesob> we could also link to alternative mirrors, like many linux distros do, hosted by well known individuals (a la DNS seeds)
19:18:56 <achow101> having mirrors would be good in general
19:19:12 <jamesob> I wonder if people who do the guix.sigs operation could optionally attach metadata declaring that they're hosting the binaries that they built... sounds maybe out of scope for this discussion though
19:19:48 <achow101> sdaftuar: maybe, I think someone has asked but got a noncommital response? or it's kind of annoying to setup?
19:20:58 <achow101> my understanding is that uploading binaries to the website is non-trivial process for whatever reason even though it seems like it shouldn't be that hard
19:21:07 <sdaftuar> if it's annoying to setup i think it's by design, to minimize the attack surface for rogue binaries being distributed from the official site due to someone being hacked
19:23:02 <sdaftuar> i would tend to think that having a secure site for distribution of our binaries makes sense? but given that the operational hassle falls on you and the other maintainers, it is tough or me to say what that process should be.
19:23:54 <jamesob> one part of me is inclined to say "doesn't matter where you get it from, check the sigs" but the more pragmatic part of me knows that there are probably a lot of people who download and run without checking signatures
19:25:50 <sdaftuar> yes i think that is undoubtedly the case
19:26:39 <pinheadmz> in that case the *link* to download the binaries is also just as vulnerable
19:26:53 <pinheadmz> i.e. if we host the website on GH we mine as well host binaries there too
19:27:00 <jonatack> In general, it seems good to avoid increased integration with github (who likely want to increase project dependence on github by offering practical lock-in features) if anything else can be somewhat practical.
19:27:03 <sdaftuar> pinheadmz: yes i think i'd be nervous about that
19:28:01 <achow101> but also not hosting with github also raises other questions about who's owns the hosting and who's paying for it
19:28:16 <achow101> that is currently an issue which I actually don't know the answer to
19:28:19 <jamesob> achow101 right
19:28:42 <willcl_ark> Would bitcoincore.org be fully deprecated (404) if we migrated?
19:28:57 <achow101> willcl_ark: no, it would just be a dns change
19:29:17 <jonatack> Seems not unimaginable for github to, for instance, be requested by govt agencies to disallow access to our binaries by people in certain locations
19:29:39 <willcl_ark> OK great, was just wondering if both might co-exist for some time which could be confusing
19:30:20 <achow101> jonatack: that would be a problem with any hosting provider, whether that's a service or a person
19:30:32 <darosior> Would be good to know if there was a reason for having the website back when it was created, other than Github not being able to distribute binaries (or was it?)
19:30:40 <BlueMatt[m]> <achow101> "that leads into the second (part..." <- I'd think that's a really bad idea - github is already a huge potential target, and we've seen dev accounts for such things compromised (not bitcoin specifically, but generally). I'd prefer we do multisig binary upload on our own hardware.
19:31:06 <BlueMatt[m]> <achow101> "the issue with release binaries..." <- uhhh, i think its literally only one, we should change that tho!
19:31:37 <BlueMatt[m]> the issue is the vast majority of people will just download the binary they find first and run it with no verificaiton
19:31:38 <lightlike> achow101: sure, the thing is that if the website goes down, people could always use the repo as an alternative, and vice versa. If everything is in one place, likely both would be shut down at the same time.
19:31:45 <BlueMatt[m]> so any mirror we add needs to be carefully considered to ensure we can secure it
19:32:32 <BlueMatt[m]> given we now need to redo binary upload access with wladimir moving on, we should make it multisig like the rest of the website machine access is.
19:33:07 <achow101> BlueMatt[m]: it's mildly annoying that we have to poke you in order to make some website changes, or when it goes kaput
19:33:45 <achow101> afaik you are a required part of the multisig access currently?
19:33:46 <BlueMatt[m]> we should update the access list tho
19:33:47 <BlueMatt[m]> you dont, many others have access, its just that none of them can be bothered
19:33:54 <BlueMatt[m]> well, many others have access all via multisig
19:34:12 <BlueMatt[m]> nope
19:34:15 <BlueMatt[m]> its 2-of-N
19:34:21 <BlueMatt[m]> i think N is 5 but I'd have to check
19:35:29 <pinheadmz> how does that work? multisig ssh ?!
19:35:35 <BlueMatt[m]> yep!
19:35:39 <pinheadmz> dope.
19:37:01 <BlueMatt[m]> anyway, if y'all get an updated access list with yubikeys and ssh keys we can redo the access set and give an intro to how it works.
19:37:02 <pinheadmz> how about the DNS / DNSSEC ?
19:37:19 <achow101> BlueMatt[m]: cool, will chat on signal about that
19:37:34 <BlueMatt[m]> what about it? yes, dnssec is on?
19:37:52 <pinheadmz> how many people can change the A records ?
19:38:05 <pinheadmz> are the dnssec keys held privately?
19:38:05 <BlueMatt[m]> sg
19:38:52 <BlueMatt[m]> I'll explain to the access list folks when we get there :)
19:39:09 <achow101> if the current maintainers can get access to the existing infra, I guess the topic is moot?
19:39:28 <achow101> anything else to discuss?
19:39:37 <jonatack> I'm willing to do website content changes, if helpful. Was doing that for a few years for optech and the review club.
19:40:00 <BlueMatt[m]> i mean we can revisit the infra, but probably best to first explain how it works on signal or so and then we can chat about if something else is better. I'm more than happy to build something better, but I'm not sure "github" is really that :/
19:40:22 <BlueMatt[m]> jonatack: fwiw this is a separate access list, that's just the github repo with pgp sigs via the existing core maintainer tools.
19:40:33 <BlueMatt[m]> the sigs are checked before going live
19:42:38 <achow101> #endmeeting