rclone / rclone

"rsync for cloud storage" - Google Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Wasabi, Google Cloud Storage, Azure Blob, Azure Files, Yandex Files
https://rclone.org
MIT License
47.19k stars 4.22k forks source link

Backblaze B2 Native API Server-Side Encryption #6585

Open pl4nty opened 1 year ago

pl4nty commented 1 year ago

What is your current rclone version (output from rclone version)?

rclone v1.60.1
- os/version: alpine 3.16.3 (64 bit)
- os/kernel: 5.15.68.1-microsoft-standard-WSL2 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.19.3
- go/linking: static
- go/tags: none

What problem are you are trying to solve?

Backblaze B2 server-side encryption is currently available in rclone via the S3 API, but S3 uses MD5 which prevents the use of --checksum with SHA1 remotes (eg OneDrive personal).

How do you think rclone should be changed to solve that?

The B2 Native API uses SHA1 and supports server-side encryption, so implementing it in rclone would allow the above combination of features.

How to use GitHub

pl4nty commented 1 year ago

I'm new to both Go and rclone, but happy to attempt implementing this. Might take a few months due to the holiday season and other projects

ncw commented 1 year ago

@pl4nty if you'd like to have a go that would be great. I skimmed the docs page and it looks like it follows quite closesly the S3 implementation, so I would copy the s3 options over into the b2 backend and then plumb them in to the API calls.

I don't think it should be too tricky.

Go is an easy language to pick up (it was designed to be easy to pick up). If you are an experienced dev then the go tour will get you up to speed and it doesn't take very long.

pl4nty commented 1 year ago

The deprecation of SHA1 for OneDrive will make my usecase redundant, but I'm still interested in implementing this. Will just be a lower priority