11:09:48 <Guest36> Hello everyone
15:13:02 <jeffro256[m]> New Vulnerability Disclosure here: https://github.com/monero-project/monero/issues/8872
15:43:28 <r4v3r23[m]> <jeffro256[m]> "New Vulnerability Disclosure..." <- > <@jeffro256:monero.social> New Vulnerability Disclosure here: https://github.com/monero-project/monero/issues/8872
15:43:28 <r4v3r23[m]> > 
15:43:28 <r4v3r23[m]> so for wallets running < 0.18.2.2, if you wait at least 1 block after funds being unlocked you are unaffected?
15:44:10 <jeffro256[m]> AFAICT, yes 
15:49:10 <r4v3r23[m]> thanks for the report
15:49:44 <Rucknium[m]>  Thank you to all who worked on this! The increase in the green line around January/February may have been caused by the mining pool block template config fix.
15:51:41 <Rucknium[m]> I agree with jeffro256  that it would be nice to at least closely examine that (privacy-critical) part of the code. As a nonprogrammer, it makes sense to me to write a specification, write code to implement the specification, and then test that the code implements the specification.
15:51:41 <jeffro256[m]> Yeah exactly, that alone caused a lot of turmoil in the values, and we might need more data over time with the patch to be more conclusive about how the bug affected selection
15:52:08 <Rucknium[m]> There are too many things in the Monero codebase that are "documented in the code". That's going to limit the pool of people able to check that the protocol is doing the right thing.
15:52:50 <Rucknium[m]> mj and I started to try to do...ex-post docuemntation of wallet2's decoy selection algorithm: https://github.com/mj-xmr/monero-mrl-mj/tree/master/decoy
15:54:52 <Rucknium[m]> He wrote python code to match some part of the wallet2 C++. I ported the Python code to R. I checked that it gave the same values (statistically) as the C++ code. I have intended to use the R code to write a closed-form math expression for what exactly wallet2 does, but I started working on other things. Maybe that could have caught the issue earlier.
15:55:16 <Rucknium[m]> I will have to write the closed-form expression eventually anyway.
15:56:39 <Rucknium[m]> It's easy to understand the "gamma picker" part. It's just a gamma distribution. But then wallet2 does many things after that in order to pick the decoys.
16:15:42 <hyc1> grumble grumble... on ubuntu 22 libhidapi-usb depends on libusb-1.0. by default, libusb-0.1 is installed on the system, and the APIs are not identical
16:16:08 <hyc1> took me a while to figure out why linking was failing with unresolved USB dependencies
17:37:51 <plowsof11> tell selsta about vulnerabilities/patches please, thanks 
18:23:14 <jeffro256[m]> <plowsof11> "tell selsta about vulnerabilitie..." <- Selsta already knows 
18:25:20 <jeffro256[m]> <hyc1> "grumble grumble... on ubuntu..." <- Does the dependency checker not catch that?
18:26:24 <plowsof11> the release would have been marked as a "recommended update" for example if selsta knew (message in the feather matrix room https://matrix.to/#/!mehPttlWNbDtNeDbvu:monero.social/$Hb6Q5_DjbmhP5GD4h9SngeTuvudWJjAI70ojVHKn3_0?via=matrix.org&via=monero.social&via=halogen.city)
18:55:56 <jeffro256[m]> Okay I did contact selsta but after a little discussion right now, I realize that I did not communicate the issue effectively, which is my bad. I assumed some information which selsta didn’t know but which I thought he/she did.
18:56:28 <jeffro256[m]> I’m sorry about that
21:12:03 <selsta> binaryFate: please add https://github.com/libexpat/libexpat/releases/download/R_2_5_0/expat-2.5.0.tar.bz2 to the depends mirror
21:12:33 <sgp[m]> jeffro256: if possible, please try to give a heads up to Cake next time an important release goes out. I was aware of 0.18.2.2 being out, but we didn't rush to upgrade the version since we didn't realize it was important. We could've shipped this fix 3 Cake versions ago. We are getting this fixed in the next Cake release, which I have given our team a specific aggressive deadline for
21:16:10 <selsta> there was miscommunication unfortunately, otherwise we would have reached out to wallet devs
21:25:00 <r4v3r23[m]> cake deserves no special treatment - you can get the info like the rest of us
21:27:46 <someoneelse49549> r4v3r23[m]: While your opinion seems to set a certain fairness between users and third-party devs, that is not a good idea. Cake Wallet have a huge userbase and having informed the cake wallet devs would have just permit to secure earlier their users.
21:28:22 <someoneelse49549> Unless you tell me it's specific to Cake Wallet, but then I don't want to dig into this
21:30:37 <r4v3r23[m]> someoneelse49549: cake wallet isnt more important than any other wallet out there
21:31:16 <r4v3r23[m]> for give them special treatment is fucking ridiculous, to ask for it even more so
21:32:56 <someoneelse49549> r4v3r23[m]: if you say so
22:01:01 <sgp[m]> how dare we attempt to be proactive at trying to patch privacy holes 🙄
22:02:06 <sgp[m]> Anyway, I hope that the previous mailing list or other discussions about how to get information out there that we've used over the years are used again going forward, for users to get important updates sooner
22:03:17 <tobtoht[m]> <jeffro256[m]> "New Vulnerability Disclosure..." <- > <@jeffro256:monero.social> New Vulnerability Disclosure here: https://github.com/monero-project/monero/issues/8872
22:03:18 <tobtoht[m]> > 
22:03:18 <tobtoht[m]> Why was the vulnerability not disclosed publicly as soon as it was found?
22:06:22 <sgp[m]> For this particular vulnerability, there doesn't seem to be any benefit to keeping it quiet until wallets update imo
22:11:35 <binaryFate> <selsta> binaryFate: please add https://github.com/libexpat/libexpat/releases/download/R_2_5_0/expat-2.5.0.tar.bz2 to the depends mirror <-- done https://downloads.getmonero.org/depends-sources/expat-2.5.0.tar.bz2
23:44:46 <BigFrog61> Hello everyone
23:45:16 <BigFrog61> Do I need to wait the end of the sync when I launch monerod ?
23:56:35 <ofrnxmr[m]> BigFrog61:  ask in  Monero  please