AllocateMiningJobTokenSuccess.mining_job_token, DeclareMiningJob.mining_job_token, DeclareMiningJobSuccess.new_mining_job_token and SetCustomMiningJob.token are bearer capabilities (the field docs say possession lets a JDC commit or identify a custom job), and AllocateMiningJobToken.user_identifier may carry client authentication material. Every one of these messages, borrowed and owned, prints the value as hex in Display and in full through derived Debug, and the parser enums delegate to them, so ordinary message logging or a panic persists a replayable credential outside the encrypted connection. #2335 fixed the copy held by channels_sv2::JobOrigin; the message types themselves still leak.
Fix: hand-written Display and Debug on these five messages (and their Owned twins) that print <redacted> for the token and identifier fields, with a regression test asserting neither the raw bytes nor their hex appear.
AllocateMiningJobTokenSuccess.mining_job_token,DeclareMiningJob.mining_job_token,DeclareMiningJobSuccess.new_mining_job_tokenandSetCustomMiningJob.tokenare bearer capabilities (the field docs say possession lets a JDC commit or identify a custom job), andAllocateMiningJobToken.user_identifiermay carry client authentication material. Every one of these messages, borrowed and owned, prints the value as hex in Display and in full through derived Debug, and the parser enums delegate to them, so ordinary message logging or a panic persists a replayable credential outside the encrypted connection. #2335 fixed the copy held bychannels_sv2::JobOrigin; the message types themselves still leak.Fix: hand-written Display and Debug on these five messages (and their Owned twins) that print
<redacted>for the token and identifier fields, with a regression test asserting neither the raw bytes nor their hex appear.