[New Release] CLI 2.4.1 to fix a bug in copying to RSA-encrypted storage

[gchen]

This is an emergency release for fixing a bug in the copy command when the destination storage is RSA-encrypted: Fixed a bug that disabled RSA when copying from a non RSA-encrypted s… · gilbertchen/duplicacy@6699e2f · GitHub

You’re affected by this bug if you’re

1. running 2.3.0 and copying from a source storage of any type (unencrypted, RSA-encrypted, and non-RSA-encrypted) to an RSA-encrypted destination storage
2. running 2.4.0 and copying from a source storage (unencrypted or non-RSA-encrypted) to an RSA-encrypted destination storage

You’ll need to clean up the storage and start from fresh; otherwise either all chunks are not encrypted by RSA (case 2), or all chunks are encrypted by RSA (case 1) causing all commands (backup, list, check, and prune) to require the private key to work.

[dreamflasher]

Would you be so kind as to elaborate what this means? Specifically:

I used the command

duplicacy init -e name b2://location

with a version prior to 2.3.0 to setup the source (and currently running 2.3.0 for backups).

• Am I using RSA encrypted destination storage?
• Are my backups encrypted?
• It sounds like I am in case 1, is my data on b2 safe/encrypted? Is it bad if the private key is required?
• Is the web version affacted, too?

[gchen]

To initialize an RSA-encrypted storage you’ll need to provide an RSA public key:

duplicacy init -e -key public.pem repository_id storage_url

See New feature: RSA encryption for details.

Your storage isn’t RSA-encrypted so you’re not affected by this bug.

For those who is affected by this bug, it is either (case 1) your storage is over-RSA-encrypted or (case 2) your storage isn’t RSA-encrypted but still encrypted by AES-GCM.