Fixes: https://github.com/aspnet/DataProtection/issues/73
On IIS where there is no user profile, the code tries to always read the 32bit registry view irrespective of the bitness of the worker process. So in case of 64 bit app pools the registry key is null so it falls back to in memory ephemeral repository. On 32 bit app pool it can find an appropriate registry key, but the keyRepositoryDescriptor is not populated resulting in a null reference exception.
Current behavior:
X86 throws
X64 falls back to in memory ephemeral
With fix:
Both X86 and X64 will use DPAPI.
- Optimistically treat failures as transient and continue to use any existing cached key ring for a short period of time
- Updates to the key ring shouldn't block other threads; they can use the outdated version while waiting for the update
- Add helpful extension methods to Interfaces project
- Auto heuristic detection now writes default protection settings to the ILogger
- Cleanup dead methods / add useful methods in DataProtectionConfiguration
- Update System.Web compatibility project to allow mapping MachineKey.Protect directly to IDataProtector.Protect
This key is used if there is no preferred default key and the developer has disabled automatic key generation. This will keep the service from falling over if the keys are not rolled and they all expire.
- Move IDataProtectionProvider, IDataProtector, and extension methods to their own package
- Simplify the APIs for registering and configuring the system
- Default implementation now auto-detects capabilities of OS
- Use EncryptedXml for X.509 certificate-based encryption
- Add ability to escrow secret material upon key creation
- Use centralized system policy for default algorithm selection
- Simplify System.Web compatibility layer
- Add unit tests, logging, and doc comments throughout solution
Pranav K
Troy Dai
N. Taylor Mullen
Brennan
Matt Ellis
Doug Bunting
Praburaj
Levi B
Hao Kung