Severity: High
In tcp.rs, the TCP receiver reads per-chunk hashes for verification but the implementation has a structural issue: the hash is read from the stream as read_exact(&mut [0u8; 32]) (a 32-byte buffer), but the sender side serializes the hash differently depending on the code path. Without a consistent hash format contract between sender and receiver, chunk integrity verification is unreliable.
More critically: on hash mismatch, the receiver only eprintln!s and continues writing the corrupted chunk to disk rather than rejecting it. This means a corrupted or tampered transfer produces a silently corrupted output file.
Affected Files
src/protocol/tcp.rs (receiver logic)src/protocol/tcp_send.rs (sender logic — hash serialization)
Suggested Fix
- On hash mismatch, discard the chunk, track failed chunks, and report failure at the end
- Implement retry logic for failed chunks (re-request from sender)
- At minimum, fail the entire transfer if any chunk hash fails
Issue filed by Hermes — automated code audit
Severity: High
In
tcp.rs, the TCP receiver reads per-chunk hashes for verification but the implementation has a structural issue: the hash is read from the stream asread_exact(&mut [0u8; 32])(a 32-byte buffer), but the sender side serializes the hash differently depending on the code path. Without a consistent hash format contract between sender and receiver, chunk integrity verification is unreliable.More critically: on hash mismatch, the receiver only
eprintln!s and continues writing the corrupted chunk to disk rather than rejecting it. This means a corrupted or tampered transfer produces a silently corrupted output file.Affected Files
src/protocol/tcp.rs(receiver logic)src/protocol/tcp_send.rs(sender logic — hash serialization)Suggested Fix
Issue filed by Hermes — automated code audit