How .NET Handles Standards Compliance that Result in Breaking Changes

Posted by Jonathan Allen on Feb 16, 2007

Sections

Process & Practices,

Architecture & Design,

Development

Topics

.NET ,

Change ,

Security

Tags

Standardization

Two security classes in .NET, HMACSHA512 and HMACSHA384, have a bug. It isn't an earth-shattering bug, but it does produce results that are inconsistent with the standard. The .NET Security team shows how this will be handed so that current applications won't break when the code gets fixed.

The HMACSHA512 and HMACSHA384 classes produces "results which are not consistent with other implementations of HMAC-SHA-512 and HMAC-SHA-384". This will be addressed in a future service pack, at which time all the programs relying on the old behavior will break.

The first step in addressing this is to add a property called "ProduceLegacyHmacValues". This will allow new programs to explicitly use the old behavior.

In order to support pre-existing programs that happen to be using the new version, a configuration value has been created. The key, legacyHMACMode, can be set in the applications configuration file or at the machine.config level.

Since not everyone is going to hear about this fix before it is too late, warning messages will be placed in the event log and when debuggers are attached to programs that use these classes. Once the change has been handled, the warning message can be disabled using the legacyHMACWarning configuration key.

InfoQ Asks, Is Microsoft handling this the right way?

 

• Older >