is there a process for assessing vulnerabilities for library/software dependencies in the monero codebase? (if there is, it is detailed anywhere?)

or do we depend on hackerone for this?

<s​yntheticbird:monero.social> midipoet: The most publicized way of learning about potential vulnerabilities in dependencies is through CVE and release bulletins. In 95% of the case it requires the project itself to report publicly the vulnerability, which happens very rarely (even linux hid vulnerability fix in bug fixes, tho now they don't care since they became CVE authority and obfuscate everything). If a p<clipped

<s​yntheticbird:monero.social> roject decide to fix something but not report it there is no way you'll ever know. Sometimes it happens that a CVE authority will fill a CVE for a vulnerability that has appears but not talked publicly. Hackerone is also offtopic. It's only used for vulnerability reporting and bug bounties. There are zero guarantees that a report will lead to a CVE being filled.

<s​yntheticbird:monero.social> I mean yeah you could check out for disclosed reports, but not everyone is disclosing it and sometimes its censored

<b​asses:matrix.org> I would report it to the maintainers of said dependency, then ask whether it is ok to warn X project (Monero for example) that is using your dependency.

<b​asses:matrix.org> but I would just report the issue to Monero immediately after informing the maintainers of that library/dependency as they are affected too.

<3​21bob321:monero.social> Hacker one ?

syntheticbird: so basically we don't have any formal, or informal, process to check for vulnerabilities in dependencies?

What's stopping a state actor targeting a software/library dependency of Monero to bring down our network then? Surely that's easier than a 51% attack, or other potential means of targeting the protocol/network. Or is that just not that feasible?

<s​yntheticbird:monero.social> midipoet, fortunately monero is pretty resilient to supply chain attack compared to say Cuprate. The only plausible target would be miniupnp, supercop and randomx are freezed, rapidjson is not even used afaik and maintained by Tencent, and gtest is maintained by Google and optional.

<s​yntheticbird:monero.social> and you have to take into account the scope of the dependency usage

<s​yntheticbird:monero.social> if we talk only vulnerability then all the dep excluding miniupnp represent zero risk

<s​yntheticbird:monero.social> oh wait there is also zmq

<s​yntheticbird:monero.social> I'm stupid i forgot like the majority of dependencies

<v​tnerd:monero.social> Rapidjson is used by zeromq only and should be pinned to a specific version

<s​yntheticbird:monero.social> yeah i see that thx

Ok, thanks for the explanation and context.

<v​tnerd:monero.social> But yeah dependencies are always sketchy, and overlooked frequently

<k​ayabanerve:matrix.org> The argument would be Monero is more at risk of issues due to self-vendoring a complete bespoke library referred to as epee, which lead to major DoS issues on the network years after the fact, and that using well-known, community-reviewed packages produce higher quality outcomes

<v​tnerd:monero.social> I don't know if that's accurate, I recall a number of the issues were in the p2p layer outside of epee. There isn't necessarily a library that does _everything_ such that it would prevent dos

<v​tnerd:monero.social> in fact only one was in the epee?

<s​gp_:monero.social> I think it's just a general point that sometimes good libraries can be better than neglected code :)

<s​gp_:monero.social> But obviously not always