<s​agewilder:unredacted.org> As I understand it, you are withholding low to medium severity vulnerabilities from the Monero team, which I believe is irresponsible. In all due respect, thinking that another knowledgeable adversary might not exist is reckless and arrogant.

<s​yntheticbird:monero.social> He is probably not going to see this message until next week.

<s​yntheticbird:monero.social> jic

<s​agewilder:unredacted.org> So he is not responsive... Hopefully, he won't be in a position where he's responsible for security and reporting.

<h​into:monero.social> I have already reported one. It will take time to lay out the problems, find solutions, then convince the project (whoever this includes) that this is important and that fixes should be worked on and merged. I haven't done so as there doesn't seem to be a party incentivized/willing to harden RPC (now and into the future).

<h​into:monero.social> I'd also note "knowledgeable/willing", the problems are relatively standard ones so I am sure many are knowledgeable, but I think there are bigger incentives elsewhere.

<s​pirobel:kernal.eu> also consider that the rpc is protected by adding hosts to a ban list if a request produces a 500 3 times from one ip /s

<s​pirobel:kernal.eu> the fastest way to make the rpc more secure would be to make getblocks.bin deterministic and let untrusted clients sync from block storage. So there is no need to expose a dynamic webservice some discussion on that here monero-project/monero #9901

<s​agewilder:unredacted.org> I better understand. I appreciate the challenges you're facing in conveying the significance of your work to the other party. However, I don't think this situation justifies withholding other vulnerabilities. Without insight into the nature of your findings, it's natural to have concerns about potential misuses from your end. Furthermore, I believe that sharing the full scope of y<clipped mess

<s​agewilder:unredacted.org> our work could actually increase incentives and encourage the project to adopt the responsible approach.

<s​pirobel:kernal.eu> this could be done for 55k (or less?) and would solve the problem indefinitely. (still don't want to discourage this effort as I am sure there will positive second order effects from working on this. Just think the direct benefit of hardening the rpc is not as big as it seems)

<s​pirobel:kernal.eu> does not seem like malintent to not disclose. just a time / resource allocation question

<s​pirobel:kernal.eu> this could be done for 55k (or less?) and would solve the problem indefinitely. (still don't want to discourage this effort as I am sure there will be positive second order effects from working on this. Just think the direct benefit of hardening the rpc is not as big as it seems)

<s​agewilder:unredacted.org> The resource allocation is to be discussed with the Monero project. In this situation, hinto made findings for a period of time but did not manage to correctly assess them or develop a mitigation. Whether it's intentions are malicious or not, they should recognize their limit and inform the security team.

<s​agewilder:unredacted.org> Informing of the state of a finding in time, is part of a responsible disclosure.

<s​pirobel:kernal.eu> if companies running a large number of public nodes are not incentivizing this work why should it be prioritized? it is on them to proactively work on this if they think its valuable. The most economic solution would be to sidestep it entirely by making getblocks.bin deterministic and upload the results to block storage and let the clients fetch from there. Then there is no need t<clipped message>

<s​pirobel:kernal.eu> o actively expose this infrastructure to untrusted clients.

What is not deterministic in getblocks.bin ?

<s​yntheticbird:monero.social> NOOOOOOOOOOOOOOOOOOOOOOOOOOO

<s​yntheticbird:monero.social> please take this discussion in #monero-dev:monero.social please

<s​pirobel:kernal.eu> it is like a box of chocolate. you never know how many blocks you will get.