The combination of us releasing a version of go-ipfs that almost forbids insure Cids but doesn't go as far as purging them from the datastore, and the release of the 6-to-7 migration created a messy situation.

There are several problems, the main one is that there is no good automatic way to deal with pinned insecure Cids. I would like to abort and tell the user to unpin them manually. To give them a chance to save the contents somehow, however, this means the user will need to install go-ipfs v0.4.14, but in order to use the migration they will need run another migration to downgrade there repo to version '6' (as the 6-to-7 conversion runs before the 7-to-8) and then unpin them with the older version of go-ipfs.

Also injecting insecure hashes and then testing that they are not in the repo after the 7-to-8 migration is difficult to do in the sharness testing. This utility could help.

So I am thinking about creating a one-off utility that works works with repo version 6,7,and 8 and has the following command:

  6-7-8-migration-helper pin-rm <hash>...
  6-7-8-migration-helper block-put <hash> 
    # ^ contents in stdin, used for testing, and allows insecure and id. hashes if the repo version < 8
  6-7-8-migration-helper block-get <hash>
  6-7-8-migration-helper dag-get <hash>
    # ^ useful in examine insure cids structure
  6-7-8-migration-helper list-insecure|list-identity

If I create this utility the binary should be provided in dist.ipfs.io somehow, probably as part of the migration.

Thoughts? Overkill?

For testing I could settle with unit tests as it far easier to inject insure hashes using code. Or maybe just find a way to hack it in the sharness testing (like manually mess with the version version string in the repo)

For the case when there are pinned insecure hashes, just tell the user what they need to do to clean up. I am hoping there are not many users with this problem but the fact that ipfs/kubo#5067 was filed mean they do exist.