<b​oog900:monero.social> epee binary has caused many issue. We also had the one recently with the write queue not having a cap IIRC.

<b​oog900:monero.social> It's not just the big libs like epee, even the small libs can have issues. This is one that comes to mind: monero-project/monero #9042 with a better system for handling dependencies this should have been fixed, for everyone, years before but we had to wait for someone to spot the issue in monerod's codebase for us to get the fix.

<k​ayabanerve:matrix.org> vtnerd: My comment was the argument for libraries is the collaboration of the community. For every user who doesn't pull in a JSON library, there's a half-baked slapped together implementation of JSON with compliance issues sitting around.

<k​ayabanerve:matrix.org> Are they less at risk of supply chain issues? Sure. Is their code of reduced quality and potentially more at risk of bugs accordingly? Also probably.

<k​ayabanerve:matrix.org> I'm not trying to say "1000 libs go brrrr". I'm just noting the other side of the argument.

<k​ayabanerve:matrix.org> Even I'm guilty of this. monero-serai has a stupid AF 100-line epee implementation in it which only supports deserializing a single object, and barely at that.

<k​ayabanerve:matrix.org> It was that or use an epee library, which in my defense would just panic on errors and I had reason not to trust :C

<k​ayabanerve:matrix.org> But now there's the quality efforts of the Cuprate project and it's hard to say there's no reason I *shouldn't* rip out my shim for their epee library and benefit from their work on completeness, efficiency, testing, and maintenance

<k​ayabanerve:matrix.org> github.com/serai-dex/serai/blob/eab…rks/monero/rpc/src/lib.rs#L821-L996 for reference of my sins

<k​ayabanerve:matrix.org> There's also the issue epee is an almost undocumented format (jeffro did write a spec iirc) with almost no other implementations that's solely in the epee library first published with CN

<k​ayabanerve:matrix.org> Don't get me wrong, I understand the history and I'm not immediately calling to completely rip it out of the protocol. I'm just noting there's a balance w.r.t. to lib or not to lib

<v​tnerd:monero.social> Iirc the only problem with epee binary was unpacking to dom, which could be an issue even when used as library (msgpack to dom likely has similar issues for instance).

<v​tnerd:monero.social> As for jh hash - is there a suitable library for this? The problem is more serious than vendored code - it's a seldomly used hash function.

<v​tnerd:monero.social> That said, would've been awesome if p2p used msgpack instead of custom format

<k​ayabanerve:matrix.org> Agreed libs can have issues. Just noting libs are always a trade off of supply chain security for perceived code quality. I'm not saying you aren't aware. I just wanted to emphasize the pro-lib argument.

<b​oog900:monero.social> I mean yes that is the main issue but it keeps coming back to bite us as we don't have the capacity to create/review/merge a good fix, although there is currently one in the pipeline AFAIK.

<b​oog900:monero.social> For jh there is in Rust, if there was a better system for deps C++ would probably have one too. It is used in CryptoNight FWIW.

<b​oog900:monero.social> My point was more on what kayaba said, not that we should rush to offload everything to deps, but that there is a trade off.

<a​ck-j:matrix.org> Side note: monero is the only service that uses epee AFAICT which makes the server response header a great fingerprint to find nodes.

<a​ck-j:matrix.org> search.censys.io/search?q=services.…+%60Epee-based%60%29&resource=hosts

<k​ayabanerve:matrix.org> Tor attempts to appear as standard HTTPS traffic. Bitcoin (with its new encrypted P2P protocol) attempts to appear identical to noise. Wen Monero indistinguishable

<k​ayabanerve:matrix.org> (I am aware there's efforts on an encrypted P2P layer but I actually don't know where those are, and can't immediately find the PR...)

<v​tnerd:monero.social> monero-project/monero #8996

<k​ayabanerve:matrix.org> monero-project/monero #8996 Found it!

<v​tnerd:monero.social> looks like I need to rebase

<v​tnerd:monero.social> yeah I had a partially written noise protocol implementation, but abandoned it as the port numbers are a giveaway 99% of the time anyway

<v​tnerd:monero.social> in the end Im not sure if there is a benefit to noise over ssl

<a​ck-j:matrix.org> Maybe not noise but p2p ssl would be great :)

<v​tnerd:monero.social> theres an optional re-use certificate mode so that endpoints can authenticate as well. disable by default since it could be used for fingerprinting easily

<v​tnerd:monero.social> but most probably shouldn’t use that, as it may be confusing (I expect only big mining operations, etc. to use it)

<k​ayabanerve:matrix.org> vtnerd: I don't believe noise is indistinguishable from the first byte.

<k​ayabanerve:matrix.org> From their own docs,

<k​ayabanerve:matrix.org> > This leaves the Noise ephemeral public keys in the clear. Ephemeral public keys are randomly chosen DH public values, but they will typically have enough structure that an eavesdropper might suspect the parties are using Noise, even if the eavesdropper can't distinguish the different handshakes. To make the ephemerals indistinguishable from random byte sequences, techniques like<clipped mess

<k​ayabanerve:matrix.org> Elligator [5] could be used.

<k​ayabanerve:matrix.org> May be used != required by and defined within the current protocol.