<achow101>
There is one preproposed meeting topic this week. Any last minute ones to add?
<achow101>
#topic package relay updates (glozow)
<dergoegge>
hi
<pinheadmz>
hi
<glozow>
Nothing new this week - #28984 is still the priority. My main focus this week will be reviewing that. I think we are aiming for #29496 and #28984 for 28.0.
<glozow>
On the p2p side, I just rebased #30111 which is the main PR to review.
<sdaftuar>
not too much from me this week either. i've rebased #28676 (on master) to try to get that code current again, and i'm planning to further get branches of that code built on sipa's cluster linearization branch (#30126) and the cluster size 2 package rbf PR
<sdaftuar>
sipa -- anything to add on your PR? (that's the one to review right now)
<sipa>
Not really, I've updated my low-level linearization code PR to include post-linearization and merging, which is all that I intend to implement at that "layer".
<sipa>
Based on review, it may mean splitting some parts off.
<glozow>
iiuc we're currently reviewing #30160 and #30161 to get those bits out of the way?
<instagibbs>
I think splitting will be necessary but haven't spent enough time on it to know how, focusing on those 2 prs first
<jon_atack>
hi
<sipa>
Indeed, those are direct dependencies, though I think it's reasonable to look at the algorithmic parts of #30126 already if you don't care that much about the data structures involved.
<sipa>
My next plan is to start helping with integration into sdaftuar's PR so we can get the TxGraph abstraction to get an implementation using these algorithms
<sipa>
But that won't change what's next for review.
<darosior>
Alright, so as you know we discussed better tracking and disclosing security bugs at the last two coredevs. About three months ago i also updated people during this meeting on Niklas and i writing about historical reports which were never disclosed. After the last coredev a few of us (dergoegge, sipa, _aj_, fanquake, achow101 and i) had a couple
<darosior>
calls to discuss what could be a good disclosure policy for the project. We came up with a plan and a disclosure policy we are content starting with. To avoid a large wall of text here i've made it into a gist: https://gist.github.com/darosior/eb71638f20968f0dc896c4261a127be6.
freesprung51269 has quit [Ping timeout: 272 seconds]
<darosior>
We'd like to seek feedback from everyone here. Keep in mind this is not set in stone, the policy may be improved or updated in the future. This is just a reasonable starting point which improves over the current situation. I can also give a TL;DR here to kick off discussions.
<sipa>
i think a tl;dr is useful
<achow101>
I guess more specific feedback can be also be left on the gist outside of the meeting?
<darosior>
TL;DR:
<darosior>
- disclose low severity bugs when a fix is released, after a pre-announcement period of 2 weeks.
<darosior>
- the plan is to gradually phase-in this policy by first disclosing all the historical reports (up to version 0.21.x). Then we do one version per month. In July all which was fixed in 22.x. In August, 23.x. Etc..
<darosior>
- disclose higher severity bugs once all affected versions are EOL, after a pre-announcement period of 2 weeks.
_andrewtoth_ has joined #bitcoin-core-dev
<darosior>
Up until we run out of EOL releases to disclose security bugs for
<sdaftuar>
Seems resonable to me on first glance -- thanks for working on this
<glozow>
+1 thanks for working on this
<achow101>
also the critical bugs that affect the entire network (e.g. inflation bug) will be handled on an ad-hoc basis
andrewtoth_ has quit [Remote host closed the connection]
<instagibbs>
+1
<darosior>
achow101: yes if people need more time to think about it feel free to comment on the gist. Since we've got no other topics i'm also fine waiting a couple minutes here for people to read through it.
<sipa>
And just to highlight what the goal is here: we'd like to improve the public's perception about some of the work that is not always very visible, and the fact that there definitely are reasons to upgrade (even to backport releases)
<darosior>
The next step would be to put up a blog post at bitcoincore.org with the historical bugs, and publish that on the ML at the same time as a request for feedback on our policy.
<darosior>
Yes, and having a proper policy in place could also potentially incentivize security researchers to look at our stuff
<sipa>
right
<josie>
overall, looks great and glad to see this moving forward. regarding high severity disclosures, do we currently send announcements for releases reaching EOL? if we will be disclosing bugs 2 weeks after EOL, maybe we also make general announcements to remind people which releases will be EOL by the next release?
<josie>
(maybe we already do this?)
<darosior>
Also it's just useful to us as a group to learn from what past bugs were vulnerabilities, and how to try and prevent them moving forward
<achow101>
josie: we don't currently. the plan would mean that we will
<pinheadmz>
darosior great writeup, good plan and +1 on blog posts, looking forward to reading those myself!
<josie>
cool, i think thats important, otherwise the 2 weeks after EOL seems a bit aggressive
<sipa>
there is also a possibility of pre-announcements like openssl does (on day X we will be disclousing a bug affecting versions Y, of severity Z)
<darosior>
pinheadmz: some are quite nice :)
<achow101>
josie: essentially we will announce eol, and pre-announce that things will be disclosed in 2 weeks
<instagibbs>
don't be afraid to extract maximum publicity for the series of posts/releases
<TheCharlatan>
is there a reason for doing one version per month in this "catch-up" period?
<darosior>
instagibbs: yeah i pinged the optech guys 👍
<darosior>
TheCharlatan: lots of 22.0 still running
<darosior>
Give a chance to people to upgrade
<achow101>
TheCharlatan: we don't want to dump everything on everyone at once since a lot of people are still running eol software. phasing in gives people time to upgrade
<sipa>
or more meta, give people some time to adapt their update processes in function of our process
<josie>
achow101: maybe we are saying the same thing, but what im suggesting is "release X is out, also as a reminder Y and Z will be EOL in the next release (~ 6 months)" and then in 6 months "hey remember those EOL releases? we will disclose bugs in 2 weeks"
<achow101>
josie: yeah, basically
<darosior>
josie: yes
<jon_atack>
lgtm. and good point josie. looking forward to reading these.
<darosior>
Cool, thanks for the feedback. I guess that's it then.
<josie>
big thanks to everyone who worked on this!
<achow101>
Any other topics to discuss?
Emc99 has quit [Quit: Client closed]
Emc99 has joined #bitcoin-core-dev
<achow101>
#endmeeting
_andrewtoth_ has quit [Remote host closed the connection]
_andrewtoth_ has joined #bitcoin-core-dev
freesprung51269 has joined #bitcoin-core-dev
Emc99 has quit [Client Quit]
twistedline_ has quit [Remote host closed the connection]
gribble has quit [Remote host closed the connection]
gribble has joined #bitcoin-core-dev
<cfields>
sdaftuar / sipa: I've started working on a boost-less txmempool. So far I have a POC dumb impl that simply hard-codes everything and naively/inefficiently uses std containers. It works and passes all tests. I'm now looking into doing it properly with custom structures and a bit more template magic. Is #28676 sufficiently far along to give me an idea of what's going to change?