1 Commits (b6924efa417464f578c019e7521e9daa2a41baeb)

Author	SHA1	Message	Date
PLus123456	b6924efa41	feat(encryption): apply destination policy encryption when relocating blobs ... Encryption is currently applied in exactly one place, while wrapping the stream of an upload request that carries an upload session with encryption metadata. A writer that moves a blob straight into a storage policy therefore stores it as it was, which is how a storage policy relocation ends up leaving plaintext on a policy that has file encryption enabled. Add RelocateBlob, which transfers the blob of an entity into another storage policy and applies that policy's encryption setting on the way. A blob that is already encrypted is transferred as ciphertext under its existing data key, so relocation costs no crypto and cannot invalidate the key held by the entity. A plaintext blob relocated into a policy with encryption enabled is encrypted during the transfer under a freshly generated data key, which is returned for the caller to persist onto the entity, along with an EncryptMetadata field on RelocateEntityParameter to commit it with. The encryption metadata is returned rather than persisted so that the plaintext data key never has to be carried in a resumable task state, and it is stripped from the returned value for the same reason. Extract the stream wrapping into encryptUploadRequest so both writers share it, and pass the request offset as the counter offset instead of a hardcoded zero. That is a no-op today, since server side encryption only ever runs on a relayed upload, which is forced into a single chunk starting at zero, but it keeps the keystream aligned for any writer that starts at an offset. Refs #3518	1 week ago