Monero

This commit changes how Monero reads 64-bit chunks from cryptographic hashes during difficulty checks. Previously the code cast a byte array directly to a uint64_t pointer, which can violate strict aliasing rules and cause unaligned or misread memory on some platforms. The new code copies the bytes with memcpy first, then converts endianness. This is a correctness and portability fix; it likely prevents subtle consensus bugs where different nodes might interpret a hash's numeric value differently, but the commit itself does not describe any active security incident or exploit.

This commit only changes two error log messages in Monero's blockchain code. It removes the phrase 'dropping connection' from messages that are printed when a peer sends an invalid chain request. The actual behavior—returning false and not dropping the connection—was already in place; the logs were simply inaccurate. There is no security fix here.

This change fixes a bug in how Monero wallet software reads payment web links (URIs). Before the fix, if a payment link did not specify an amount, description, or other optional fields, the wallet could accidentally keep leftover values from a previous parse. That could mislead the user into sending the wrong amount or seeing wrong payment details. The patch now clears those fields right after confirming the address is valid, and adds a test to prove it.

This commit fixes the 'donate' command in Monero's command-line wallet. Previously, the command accepted an optional extra argument (an obsolete payment ID) and its argument-count check allowed up to 5 items. The code then tried to read the last item as an amount after optionally popping the payment ID, which could lead to reading from an empty argument list or misinterpreting arguments. The patch removes the obsolete payment ID handling and tightens the argument limit to 4, preventing the out-of-bounds or misdirected read. There is no evidence in the commit that this was exploitable for code execution or theft; it appears to be a defensive correctness fix.

This commit changes the Monero daemon's OpenRC service script so that it now requires ('needs') a working network and uses DNS, rather than merely starting after the network service. This is a service-dependency hardening fix: it helps ensure the Monero daemon does not start without network connectivity, which could prevent misbehavior or partial startup failures. It is not a code vulnerability fix and does not directly allow an attacker to exploit the daemon.

This change tightens security for Monero wallet users who connect to a daemon through a proxy (such as Tor or I2P). Previously, when a proxy was used, the wallet did not require users to supply a way to verify the daemon's SSL certificate. That could let a malicious exit node or proxy operator impersonate the daemon and steal wallet data or funds. The patch now requires strong verification (a known certificate, fingerprint, or an onion/i2p address) whenever a proxy or SSL is used.

This change makes the Monero wallet RPC server refuse to start if its SSL/TLS-related settings are incomplete or invalid. Previously, the server may have started anyway when only a wallet directory was supplied, potentially leaving the RPC interface in an unintended security state. The fix validates the configuration early by running a dummy wallet creation check before proceeding.

This commit adds new cryptographic code to Monero that converts points on the Ed25519 curve into Weierstraß (short Weierstrass) form. It introduces helper functions, new curve constants, and unit tests, but does not appear to fix any known vulnerability. The change is a feature addition for the FCMP++ (Full Chain Membership Proofs) work. There is no direct evidence in the commit or supplied references that this patch addresses a security bug, but any new elliptic-curve conversion code carries implementation-risk that could affect correctness or side-channel resistance if used incorrectly.

This commit fixes the way Monero's internal JSON serializer handles special low-value characters (control characters). Previously, characters such as vertical tab and other invisible control characters were either escaped in non-standard ways or left unescaped, which could produce JSON that violates the official JSON standard (RFC 8259). Invalid JSON can confuse other programs that read Monero's output, and in the worst case could be abused to alter how data is parsed or to inject unexpected content. The patch now correctly escapes all control characters and adds tests to prove it.

This commit adds a new cryptographic safety check for Monero's upcoming FCMP++ (Full Chain Membership Proof) system. It makes sure that certain elliptic-curve points used in transactions are free of small 'torsion' components—mathematical artifacts that can be exploited in some zero-knowledge proof attacks. The patch introduces helper functions to clear torsion and a new validation routine, plus tests. It does not by itself fix a known exploitable bug in live code; it is a defensive hardening measure for a feature that is still being integrated.

This commit fixes a bug in Monero's wallet software where exporting 'key images' (cryptographic proofs that help verify account balances without exposing private keys) could use an outdated cached value instead of the freshly generated correct one. The change ensures the wallet always exports the newly generated key image, and adds a test to confirm this behavior. If the wrong key image were exported, a wallet relying on it could fail to prove ownership of funds correctly, potentially causing accounting errors or denial of service in balance verification.

This commit changes how Monero's wallet code copies sensitive cryptographic data (secret keys, transaction hashes, payment IDs) from one memory location to another. Previously it used direct pointer casting, which can violate strict type alignment rules and may cause undefined behavior on some platforms. The patch replaces those casts with explicit memory copies (memcpy). This is a defensive hardening change: it reduces the risk of crashes or misaligned memory reads, but the commit itself does not claim to fix an active exploit or known vulnerability.

This commit narrows a long-standing special-case workaround for Monero block 202612. Previously, any new blockchain fork would have inherited a hard-coded proof-of-work hash at that exact height, which could stop nodes from syncing or miners from producing valid blocks if the network's difficulty was higher than the fixed value. The change now applies the workaround only to the known historical mainnet, testnet, and stagenet blocks, so new or private chains compute proof of work normally.