01:01:11 <jtgrassie> greenpillow11[m]: rbrunner: IIRC RR 8149 addressed the multisig issues
01:01:28 <jtgrassie> https://github.com/monero-project/monero/pull/8149
07:36:32 <ofrnxmr[m]> I remember.
07:36:32 <ofrnxmr[m]> Ooo is the only one who can answer on the vulnerabilities that still exist 
07:47:18 <jeffro256[m]> I miss him/her
07:47:23 <jeffro256[m]> Everyday
07:50:07 <jeffro256[m]> moneromooo Does this commit https://github.com/monero-project/monero/pull/5370/commits/4d29e80aae376e116cecc59c82d7871c9f66ba96#diff-d229136ad349270fc2700a14156517556c003df8494b0233c526046430e57d57 work because copy elision is not done with crypto::secret_key b/c of the non-trivial destructor?
07:58:17 <moneromooo> I am not sure. It works because it is using the same local instead of recreating one per loop.
07:58:31 <moneromooo> So ctor/dtor don't constantly get called for a new object.
07:58:38 <moneromooo> Does that answer your question ?
07:59:24 <jeffro256[m]> ohhhhhhhhhhhhhhhhhhhhhh
08:00:12 <jeffro256[m]> Yes that answers it. I though for some reason the C++ compiler was calling ctor/dtor before AND after returning the crypto::secret_key from the function
08:01:12 <jeffro256[m]> Like 1. ctor/dtor 2. copy value in stack 3. ctor/dtor
08:01:55 <jeffro256[m]> Thanks
08:09:18 <jeffro256[m]> git grep -E 'secret_key +[a-zA-Z0-9_:]+\('
08:09:45 <jeffro256[m]> There's a lot of functions that return secret_keys. Maybe could be a good avenue for similar optimizations
08:11:16 <moneromooo> You'll see mlock/munlock in the profile if you find one.
08:16:53 <jeffro256[m]> "in the profile"?
08:17:19 <moneromooo> I mean the output of, eg, perf top.
08:19:12 <jeffro256[m]> Ah gotcha 
09:09:15 <jeffro256[m]> Now it is too late and wouldn't really be worth the effort, but a custom allocator could have been interesting for this. Call it MlockScrubAllocator. One giant chunk of memory is allocated once with mlock() called once on allocation and munlock() called once on deallocation. Deallocs thru our allocator would scrub the used memory automatically. And crypto::secret_key (or any other type which we want to have these properties) would be
09:09:15 <jeffro256[m]> a RAII pointer allocated thru our custom allocator. 
09:43:04 <rbrunner> jtgrassie: 
09:43:04 <rbrunner> "greenpillow11[m]: rbrunner: IIRC RR 8149 addressed the multisig issues"
09:44:03 <rbrunner> Thanks. Yes, but we *still* label it experimental in the latest release, if I remember correctly? Especially in the CLI wallet