Merge pull request #9632

e2eea7b Fix --anonymous-inbound data leak (Lee *!* Clagett)
This commit is contained in:
tobtoht 2025-01-14 14:25:48 +00:00
commit c599916113
No known key found for this signature in database
GPG Key ID: E45B10DD027D2472

View File

@ -2487,6 +2487,20 @@ namespace nodetool
std::vector<peerlist_entry> local_peerlist_new;
zone.m_peerlist.get_peerlist_head(local_peerlist_new, true, max_peerlist_size);
/* Tor/I2P nodes receiving connections via forwarding (from tor/i2p daemon)
do not know the address of the connecting peer. This is relayed to them,
iff the node has setup an inbound hidden service.
\note Insert into `local_peerlist_new` so that it is only sent once like
the other peers. */
if(outgoing_to_same_zone)
{
local_peerlist_new.insert(
local_peerlist_new.begin() + crypto::rand_range(std::size_t(0), local_peerlist_new.size()),
peerlist_entry{zone.m_our_address, zone.m_config.m_peer_id, 0}
);
}
//only include out peers we did not already send
rsp.local_peerlist_new.reserve(local_peerlist_new.size());
for (auto &pe: local_peerlist_new)
@ -2497,17 +2511,6 @@ namespace nodetool
}
m_payload_handler.get_payload_sync_data(rsp.payload_data);
/* Tor/I2P nodes receiving connections via forwarding (from tor/i2p daemon)
do not know the address of the connecting peer. This is relayed to them,
iff the node has setup an inbound hidden service. The other peer will have
to use the random peer_id value to link the two. My initial thought is that
the inbound peer should leave the other side marked as `<unknown tor host>`,
etc., because someone could give faulty addresses over Tor/I2P to get the
real peer with that identity banned/blacklisted. */
if(outgoing_to_same_zone)
rsp.local_peerlist_new.push_back(peerlist_entry{zone.m_our_address, zone.m_config.m_peer_id, std::time(nullptr)});
LOG_DEBUG_CC(context, "COMMAND_TIMED_SYNC");
return 1;
}