00:25:26 epee binary has caused many issue. We also had the one recently with the write queue not having a cap IIRC. 00:25:27 It's not just the big libs like epee, even the small libs can have issues. This is one that comes to mind: https://github.com/monero-project/monero/pull/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. 00:28:31 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. 00:29:05 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. 00:29:31 I'm not trying to say "1000 libs go brrrr". I'm just noting the other side of the argument. 00:30:08 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. 00:30:32 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 00:31:11 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 00:32:07 https://github.com/serai-dex/serai/blob/eab5d9e64fd27076a49583e5f45901d34b463c01/networks/monero/rpc/src/lib.rs#L821-L996 for reference of my sins 00:32:44 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 00:33:20 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 00:37:00 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). 00:37:01 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. 00:37:30 That said, would've been awesome if p2p used msgpack instead of custom format 00:39:39 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. 00:41:56 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. 00:44:39 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. 00:44:41 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. 01:06:50

Side note: monero is the only service that uses epee AFAICT which makes the server response header a great fingerprint to find nodes. 01:06:51

https://search.censys.io/search?q=services.http.response.headers%3A+%28key%3A+%60Server%60+and+value.headers%3A+%60Epee-based%60%29&resource=hosts 01:43:30 Tor attempts to appear as standard HTTPS traffic. Bitcoin (with its new encrypted P2P protocol) attempts to appear identical to noise. Wen Monero indistinguishable 01:46:04 (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...) 01:47:28 https://github.com/monero-project/monero/pull/8996 01:47:30 https://github.com/monero-project/monero/pull/8996 Found it! 01:47:32 looks like I need to rebase 01:48:00 yeah I had a partially written noise protocol implementation, but abandoned it as the port numbers are a giveaway 99% of the time anyway 01:48:51 in the end Im not sure if there is a benefit to noise over ssl 01:49:40

Maybe not noise but p2p ssl would be great :) 01:51:12 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 01:51:54 but most probably shouldn’t use that, as it may be confusing (I expect only big mining operations, etc. to use it) 07:10:57 vtnerd: I don't believe noise is indistinguishable from the first byte. 07:14:08 From their own docs, 07:14:09 > 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 Elligator [5] could be used. 07:14:24 May be used != required by and defined within the current protocol. 15:55:46 yeah its really difficult to hide the first key exchange, elligator? I guess would do it, but probably not worth the complexity 16:47:42 midipoet: I made an effort to reduce the number of statically linked build dependencies. If you compare `contrib/depends/packages` on `release-v0.18` with `master`, you'll find that it has down from 34 to 16 packages (of which only 11 are relevant for Linux targets). 16:47:50 Note: some of these packages weren't built at all, some were built but unused (e.g. icu4c, unwind), some were not needed (e.g. eudev, expat, libiconv). 16:47:59 I keep track of the versions used and which packages have CVEs here: https://github.com/monero-project/monero/issues/9669 16:48:11 Versions listed are for the master branch, but I try to PR upgrades to the release branch if a vulnerability plausibly affects release builds. 16:48:23 When I PR an update to a dependency, I run a number of checks to mitigate the risk of a supply chain attack. (See e.g. https://github.com/monero-project/monero/pull/9273) 16:48:37 If a package contains binary files, they get removed: https://github.com/monero-project/monero/blob/master/contrib/depends/packages/openssl.mk#L55 16:48:54 I also manually scroll through the diff to check for anything suspicious, like long hex strings, and check whether the dep has been packaged for distributions using kpcyrd's whatsrc.org. 16:49:17 I've moved the release build environment from Gitian (which meant trusting hundreds of opaque binary packages from Ubuntu servers) with Guix to achieve full-source bootstrappability for release builds. See: https://github.com/monero-project/monero/pull/8929 16:49:30 I'm actively working on reducing the number of packages in Monero's bootstrap graph. Since January, the total number of packages has gone down by 22%. See: https://github.com/monero-project/monero/issues/9684 16:49:41 And will go down further after #10005 is merged. 17:03:33 Rust will fuck everything up (cross-architecture non-determinism, greatly increased time to bootstrap, and lord knows how many new third-party dependencies). 17:03:42 See: https://github.com/monero-project/monero/pull/9801 and https://github.com/seraphis-migration/monero/blob/fcmp%2B%2B-stage/src/fcmp_pp/fcmp_pp_rust/Cargo.lock 17:04:14 I am _not_ happy about this. But it was it is. The benefits of FCMP++ outweigh the risks. 17:04:33 i can understand the pain 17:36:33 Hi 17:36:39 we can continue SLVer Bullet discussion here 17:41:19 I think this is a point worth harping on. Did they read the updated version, or not? Was their comment in regards to the new v3 or the previous version? 18:11:22 I believe Diego Salazar is an immense boon to the Monero project, who we are lucky to have, and intended nothing wrong in the (ongoing) MRL meeting. I apologize if I was too harsh. 18:11:28 I take umbrage to the fact that potentially getting PUP to fund a third theory audit is: 18:11:29 1. A misuse of their funds 18:11:31 2. Circumventing the oversight process. 18:11:33 MRL oversight process has the domain of MRL CCS funds as pertains to FCMPs. Me thinking that something else is important, and finding someone else to fund it separately does not equate to a misuse of fudns in general. 18:13:01 MRL oversight has decided that a third theory audit is not priority right now. I agree with this as it pertains to MRL CCS funds. 18:13:01 I separately know that there is a group that is willing to help fund parallel things. Just because MRL CCS funds will not be immediately mobilized for this portion (rightfully so) does not mean an external benefactor would be ill-advised to do so. 18:13:28 I write every message with the knowledge that you are a good actor and a good friend. :) 18:13:53 We can disagree on things. It's fine. 18:13:58 My opinion, as one of the people trusted with FCMP++ research funding, is an audit should be prioritized over a third review. While I can be avoided by avoiding the dedicated FCMP++ research funds, I was attempting to note my position existed for a reason and I do not believe immediately deferring to an outside fund pool to be responsible. 18:14:18 Though I don't inherently have a place to comment as it isn't _my money_. 18:14:53 Also welcome ben_sepanski and Alp Bassa from Veridise. Feel free to leave your comments on all of this too. :) 18:14:55 My primary concern is simply it'd be ineffective compared to a joint-organized effort and potentially disruptive if occupying a limited resource the FCMP++ effort desires. 18:17:34 If we have a reasonable offer and lack funding, I have no issue asking for donations. I have issue with doing unreasonable things simply because we can. Obviously, with more money, more things become reasonable, but my primary comment is let's just keep things in the loop? If this gets bogged down in another MRL meeting, and the goal is simply avoiding needing the agreement on fun ding which is delayed, I have no objections. 18:17:55 But right now, myself, jberman, Rucknium, and rbrunner seemingly agree an audit is of higher priority than a third review. 18:21:44 I don't mind circumventing funding. I mind circumventing what the community believes is the best path forward _in a way disruptive to the community_. 18:22:00 (sorry if I'm hammering this in to much) 18:22:03 (sorry if I'm hammering this in too much) 18:22:23 I disagree, but I will hold off. 18:22:53 You guys are project leads for FCMP here, and if you find it disruptive then it's enough for me to completely step off. 18:23:00 IF you found it neutral or positive I would move forward. 18:23:05 If you found it neutral or positive I would move forward. 18:24:13 Immediately, I want to defer to sgp to source quotes covering the discussion and then circle back from there. That shouldn't be disruptive, or delaying, to anyone, and should accomplish everyone's individual desires. 18:24:31 It's only deciding on which quote to move forward with which may be problematic if individuals disagree and want conflicting quotes. 19:20:36 tobtoht_: that's amazing. Thanks for all your hard work!