Using URL keys can lead to data loss. Two remotes can have two different objects for the same URL key, as the content of an url may change over time. If git-annex gets part of an object from the first remote, but is then interrupted or fails, and then resumes from the second remote's object, it will stitch together a chimera that has never existed at the url. Then dropping the URL objects from both remotes will result in no valid copies of the object remaining.

This could also happen with WORM, but it would be much less likely. Two files with the same mtime, size, and path would have to be added to two repos.

And it could happen if an old git-annex is being used in a repo that uses some new key that it doesn't support, like a new checksum type.

Special remotes are affected if they use chunking, or if they resume when the destination file already exists and don't have their own checksumming. So the rsync special remote is affected when it's used with chunking, but not otherwise.

With the default annex.security.allow-unverified-downloads config, encrypted special remotes already don't allow downloading the problem keys.

The bug affects remotes using the git-annex P2P protocol, but not ssh remotes using rsync. So the introduction of the P2P protocol made this bug more prevelant.

Best fix for this seems to be to prevent resuming download of keys when their content is not verifiable.

The P2P protocol could also be extended to use a checksum to verify a resume is safe to do. That would only be worth doing for the affected keys.