There was a bug in Tarsnap 1.0.20 (February 2009) which had a ~ 0.2% chance of causing silent data corruption if people were using the new --checkpoint-bytes option. (The bug actually had two possible consequences, silent data corruption and exiting with an error, and my analysis showed that the second was about 500x more likely to occur first.)
Fortunately this was a new feature and I was able to identify which people had used it (since it relies on server-side functionality and I had good logs) so I could email all the potentially-affected users to warn them.
Uhh... let me look back at that code. My memory isn't what it used to be... right, now I remember. Sort of.
So, Tarsnap uses a "chunkification cache" to speed up archiving; when it chews through a file and splits it into chunks, it records "file X was N bytes, had inode #I, and was last modified at time T, and here's the chunks it was split into". The next time it sees the file, it starts by stat()ing the file and if those parameters match it reuses the chunk list rather than reading the file from disk and splitting it into chunks again.
With checkpointing enabled, if a checkpoint occurred in the middle of a file a truncated entry (to be specific, the chunk list for the portion of the file which had been processed) would be stored in the chunkification cache. If a later tarsnap process read that it was possible that it would archive the file wrong (I think it would be truncated, but I'm not absolutely certain right now). The fix was simply to not use an entry from the chunkification cache if it wasn't internally consistent.
Fortunately this was a new feature and I was able to identify which people had used it (since it relies on server-side functionality and I had good logs) so I could email all the potentially-affected users to warn them.