Migration Guide - robinrodricks/FluentStorage GitHub Wiki

Migrating from Storage.NET

Packaging changes

Change your NuGet packages and your imports using this mapping:

Old name	New name
Storage.Net	FluentStorage
Storage.Net.Amazon.Aws	FluentStorage.AWS
Storage.Net.Gcp.CloudStorage	FluentStorage.GCP
Storage.Net.Databricks	FluentStorage.Databricks
Storage.Net.Ftp	FluentStorage.FTP
Storage.Net.Microsoft.Azure.Storage.Blobs	FluentStorage.Azure.Blobs
Storage.Net.Microsoft.Azure.Storage.Files	FluentStorage.Azure.Files
Storage.Net.Microsoft.Azure.EventHub	FluentStorage.Azure.EventHub
Storage.Net.Microsoft.Azure.ServiceBus	FluentStorage.Azure.ServiceBus
Storage.Net.Microsoft.Azure.KeyVault	FluentStorage.Azure.KeyVault
Storage.Net.Microsoft.Azure.ServiceFabric	FluentStorage.Azure.ServiceFabric
Storage.Net.Microsoft.Azure.Queues	FluentStorage.Azure.Queues
Storage.Net.Microsoft.Azure.DataLake.Storage.Gen1	FluentStorage.Azure.DataLake

Encryption changes

We now accept the IV and Key in the constructors of the *EncryptionSink classes.

Since most of the time we will be using Dependency Injection (DI) to instantiate our objects, each time the SymmetricEncryptionSink, the IV is set

		public AesSymmetricEncryptionSink(string key) {
			_cryptoAlgorithm = Aes.Create();
			_cryptoAlgorithm.Key = Convert.FromBase64String(key);
			_cryptoAlgorithm.GenerateIV();
		}

This means that if a blob is stored, then it can only be unencrypted using the same instance of the Sink or with an instance of the Sink with the same IV (secret key)

If you are storing to AWS/Azure storage, then if you try and retrieve the blob at another time, you can't read the blob even though the original key might be the same, the secret generated at the time of encryption is no longer the secret that the sink is trying to use the decrypt.

Storage.Net has got this wrong and has used a pattern like this, which creates a transient class, however we fixed it to accept the IV and Key in the constructors of the sinks.