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.