Monero

This commit refactors how some Monero ZeroMQ publication messages are serialized to JSON. It introduces a new internal JSON writer library and switches a few ZMQ-PUB message types over to it. The change is primarily a code cleanup and modernization; it does not appear to fix a known security bug or introduce an obvious new vulnerability. One small improvement is that serialization errors are now checked and logged instead of silently producing malformed output.

This Monero code change fixes how the transaction memory pool tracks 'sensitive' transactions—those that have not yet been publicly broadcast, such as Dandelion++ stem-phase transactions. Previously, incremental RPC queries could leak these sensitive transactions to clients that should not see them. The patch adds a per-transaction 'sensitive' flag so that RPC responses can skip these transactions. This is a privacy/confidentiality fix, not a direct theft-of-funds bug.

This Monero update fixes a problem where the daemon's 'get blocks' RPC reply could grow too large and exceed network packet limits. The patch makes the mempool (pool of pending transactions) portion of the response respect a size budget, so it won't be added if the blocks part already fills most of the safe packet size. It also adds internal limits on how many transaction details and how much total transaction blob data are returned. The likely goal is to prevent oversized replies that could cause connection failures or denial-of-service issues for wallets and other nodes.

This commit updates Monero's SSL certificate generation code to use newer OpenSSL 3.0 APIs instead of older, deprecated ones. It is primarily a compatibility and cleanup change: it replaces low-level RSA key creation with the modern EVP_RSA_gen function when OpenSSL 3.0+ is available, and removes an unused elliptic-curve certificate function. There is no direct security vulnerability being fixed here, but keeping up with current APIs reduces future maintenance risk and avoids deprecation warnings.

This commit fixes a minor logging bug in the Monero peer-to-peer protocol code. The previous code accidentally added a number to a character (using '+' instead of '<<'), which produced incorrect characters in a debug peer-overview string. The fix simply prints the number and character separately. There is no security impact.

This commit removes two old command-line debug options, --test-drop-download and --test-drop-download-height, that were added in 2015 to help developers manually test network behavior by discarding downloaded blocks. The commit deletes the option definitions, the code that read them, the code that skipped block processing when they were set, and related shell-completion hints. There is no security fix here; it is a cleanup of unused debugging flags.

This commit is a large repository initialization or merge that adds the entire Monero codebase plus build/CI files. The stated purpose is to speed up the blockchain export tool by reading the database more efficiently. There is no indication in the commit message or the visible changes that this is a security fix or introduces a security vulnerability.

This commit is a large-scale spelling and typo correction across comments, documentation, and a few string literals. It changes no program logic, no function behavior, and no executable code paths. There is no security relevance.

This commit is titled as a fix for the blockchain database's 'remove_block' function, specifically that the cursor should be set before deletion. However, the actual supplied diff is enormous (665,233 added lines across 1,321 files) and appears to be a full repository import or merge rather than a focused patch. The specific code change described in the title cannot be verified from the provided diff because the relevant file (src/blockchain_db/lmdb/db_lmdb.cpp) is not shown in the diff excerpt. The security relevance is therefore uncertain based only on the materials given.

This commit updates a bundled external component called RandomX from one version to another (v1.2.2). The actual code changes are not visible because the diff was not provided, and no verified references were supplied. Without seeing what changed, it is impossible to tell whether this update fixes a security problem, fixes a regular bug, or just refreshes the dependency.

This commit changes how Monero stores and loads a list of sensitive multisignature wallet keys. Previously, the code used a generic 'copy the raw bytes' path for a container of secret keys. That generic path could leave copies of secret key bytes in temporary memory or use a copy method not safe for non-trivial types. The patch forces the keys to be converted through an explicitly cleared intermediate type and adds a compile-time guard so the generic blob-copy helper can only be used on simple, safe types. In short: it reduces the chance that secret key material leaks or gets mishandled during wallet serialization.

This commit swaps the two arguments in two calloc() calls so they follow the conventional order (number of elements first, then element size). On standard platforms this produces identical memory allocation results and does not change program behavior or fix any security bug. It only silences compiler warnings.

This commit fixes a privacy gap in Monero's restricted ZeroMQ RPC mode. Before the patch, someone using the --restricted-zmq-rpc option could still see exact times when transactions arrived and were last relayed through the get_transaction_pool ZMQ call. The HTTP restricted mode already hid those timing details, but the ZMQ path did not. The patch adds the same on/off privacy filter to the ZMQ path so restricted callers now get zeroed-out timestamps, matching restricted HTTP behavior. Timing metadata can help an observer deanonymize or trace transactions, so this is a privacy hardening fix.

This commit is a routine build-system cleanup. It removes the Boost Chrono library from the link lists of components that don't actually use it, and adds it to the one component that does. There is no change to program logic, no bug fix, and no security relevance visible in the diff.

This is a code-quality refactor, not a security fix. It replaces an older, heavier C++ scope-cleanup helper with a lighter, modern one. The change touches several parts of the program but does not add or remove any security behavior; it only changes how cleanup actions are expressed internally.

This change makes Monero's HTTP digest authentication code handle failures in the MD5 hashing functions more gracefully. Previously, if OpenSSL's MD5 operations failed (for example, because MD5 was disabled in the cryptographic library), the code would silently continue with invalid or empty hash values, potentially allowing authentication to proceed incorrectly. Now the code checks each hashing step and aborts the authentication attempt cleanly if MD5 cannot be computed.

This is a routine code modernization change. It replaces an older, deprecated Boost networking function called strand.wrap with the newer equivalent bind_executor in two files. There is no indication this fixes a security bug; it simply keeps the code compatible with newer versions of the Boost library.

This commit fixes a thread resource leak in Monero's cryptography code. Previously, a helper macro called CTHR_THREAD_CLOSE was defined as doing nothing, meaning threads were created and joined but never properly detached. On systems using POSIX threads (pthreads), this can leave thread resources unreleased, causing gradual memory use growth. The fix makes CTHR_THREAD_CLOSE call pthread_detach, which tells the system it can clean up the thread after it finishes. This is a reliability and resource-management fix rather than a direct remote exploit, but resource exhaustion can sometimes affect service availability.

This Monero patch fixes a RingCT amount-decoding function that previously ignored extra bytes beyond the first 8 in a 32-byte amount field. A pre-v10 'long amount' transaction could hide non-zero padding after the real amount. The receiver's wallet would fail to decode it, but a third-party wallet checking a proof might accept it, creating a mismatch between what the sender proves and what the recipient can actually spend. The change makes the decoder reject such malformed amounts.

This commit simply removes unused helper functions from a cryptographic source file to silence compiler warnings. No behavior changes, no bug fixes, and no security issue is present in the diff.

This is a minor code cleanup that moves preprocessor guards (#if defined __i386 || defined __x86_64__) so that two x86-only byte arrays are only compiled on x86 platforms. It eliminates a compiler warning about unused constant variables on non-x86 builds and has no security relevance.

This commit fixes a test-only data-directory path so that certain internal test modes once again store their temporary blockchain data in a separate 'fake' folder rather than potentially mixing with the main config folder. It does not change live mainnet/regtest node behavior and appears to be a regression fix for unit-test isolation.

This change moves a duplicate-transaction check so it only runs after the peer connection is in a normal, ready state. Before, a peer could send transaction data during protocol setup, and the node would parse and validate those transactions before confirming the connection was properly established. The patch prevents unnecessary processing of potentially malformed or duplicate transaction blobs during handshake phases.

This commit is a routine cleanup that removes unused variables and adds one safety check. It fixes compiler warnings about variables being assigned but never read. The only functional change is a new error throw if a reserve proof signature fails to parse, which makes the wallet fail more cleanly instead of continuing with bad data. There is no indication this fixes an active security vulnerability.

This commit only fixes compiler warnings by adding the word 'void' inside empty parentheses of three C function definitions. In C, empty parentheses mean something slightly different than '(void)', so modern compilers warn about it. This is a code-quality cleanup with no security effect.