[API Proposal]: ability to have stable hash codes

[insouciiance]

Background and motivation

Currently, certain types & methods use Interop.GetRandomBytes (e.g. HashCode or string.GetHashCode) to have a random seed for hash codes, meaning they return different hash for the same value on different program runs.

However it would really nice to have the ability to stabilize all hash codes across multiple runs.
One use case for this feature would be to detect changes in behaviour on CI and verify if those were intended or not. To have deterministic rendering results we would expect deterministic hash codes so that, for example, enumerating a set or a dictionary is stable (of course no ordering is expected at all, but it should be deterministic).

API Proposal

[AttributeUsage(AttributeTargets.Assembly)]
public sealed class AssemblyStabilizedHashCodeAlgorithmAttribute : Attribute
{
    public bool Enabled { get; }

    public AssemblyStabilizedHashCodeAlgorithmAttribute(bool enabled);
}

API Usage

<ItemGroup>
  <AssemblyAttribute Include="System.Runtime.AssemblyStabilizedHashCodeAlgorithm">
    <_Parameter1>true</_Parameter1>
  </AssemblyAttribute>
</ItemGroup>

or

[assembly: System.Runtime.AssemblyStabilizedHashCodeAlgorithm(true)]

Alternative Designs

<PropertyGroup>
    <UseStabilizedHashCodeAlgorithm>true</UseStabilizedHashCodeAlgorithm>
</PropertyGroup>

Risks

Hash code randomization is good for security, prevention against DoS attacks, etc. Having stable hash codes across runs may result in hash flooding, so it needs to be toggled explicitly via the assembly attribute or the .csrpoj property.

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

Currently, certain types & methods use Interop.GetRandomBytes (e.g. HashCode or string.GetHashCode) to have a random seed for hash codes, meaning they return different hash for the same value on different program runs.

However it would really nice to have the ability to stabilize all hash codes across multiple runs.
One use case for this feature would be to detect changes in behaviour on CI and verify if those were intended or not. To have deterministic rendering results we would expect deterministic hash codes so that, for example, enumerating a set or a dictionary is stable (of course no ordering is expected at all, but it should be deterministic).

API Proposal

[AttributeUsage(AttributeTargets.Assembly)]
public sealed class AssemblyStabilizedHashCodeAlgorithmAttribute : Attribute
{
    public bool Enabled { get; }

    public AssemblyStabilizedHashCodeAlgorithmAttribute(bool enabled);
}

API Usage

<ItemGroup>
  <AssemblyAttribute Include="System.Runtime.AssemblyStabilizedHashCodeAlgorithm">
    <_Parameter1>true</_Parameter1>
  </AssemblyAttribute>
</ItemGroup>

or

[assembly: System.Runtime.AssemblyStabilizedHashCodeAlgorithm(true)]

Alternative Designs

<PropertyGroup>
    <UseStabilizedHashCodeAlgorithm>true</UseStabilizedHashCodeAlgorithm>
</PropertyGroup>

Risks

Hash code randomization is good for security, prevention against DoS attacks, etc. Having stable hash codes across runs may result in hash flooding, so it needs to be toggled explicitly via the assembly attribute or the .csrpoj property.

Author:	insouciiance
Assignees:	-
Labels:	api-suggestion, area-System.Runtime, untriaged
Milestone:	-

[huoyaoyuan]

Adjusting behavior of code (like HashCode.Combine) based on calling assembly is very slow because of reflection, and not resilient for assembly-manipulating build operations like trimming. Transitive calls are also hard to address, for example calling GetHashCode from fields with type defined from other assembly, including CoreLib.

Instead, having a process-wide AppContext switch to provide a seed for well-known hashcode providers is much more achievable. User-defined GetHashCode and object identity-based hash code are of course not covered, but it can be used for stablize string.GetHashCode and HashCode.Combine, and make their results deterministic. It can also be turn on only in test process.

Cross-version deterministic should not be guaranteed to allow algorithm evolving. Fixed hash code seed + fixed runtime version can produce deterministic hash code for testing.

[jkotas]

The hashcode randomization is a security feature. For example, if you set this switch in your ASP.NET Core app, it would likely become vulnerable to denial-of-service attack.

Configuration switches to disable security features have extremely high bar. I do not see this proposal ever meeting that bar.

[tannergooding]

Closing as not planned as per the above.