ComputeComponentTypeNameHash does not handle multi-byte type names correctly

[vcsjones]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

👋 I was looking though the use of cryptography in ASP.NET Core, and stumbled on this code block:

aspnetcore/src/Components/Endpoints/src/Rendering/SSRRenderModeBoundary.cs

Lines 206 to 213 in 46562b1

	var typeNameLength = typeName.Length;
	var typeNameBytes = typeNameLength < 1024
	? stackalloc byte[typeNameLength]
	: new byte[typeNameLength];
	Encoding.UTF8.GetBytes(typeName, typeNameBytes);
	Span<byte> typeNameHashBytes = stackalloc byte[SHA1.HashSizeInBytes];

Nothing about the use of cryptography there concerns me too much, but I did want to point out that it does not handle types where the type name requires the use of multibyte characters.

I lack detailed knowledge of how SSR works, so I had a bit of trouble trying to reproduce it in a real app.

Expected Behavior

No response

Steps To Reproduce

I had a bit of trouble trying to reproduce this using an app, as I am not super familiar with the innards of SSR. However, in isolation it can be reproduced with:

using System;
using System.Text;
using System.Security.Cryptography;

string hash = ComputeComponentTypeNameHash(typeof(こんにちは));
Console.WriteLine(hash);

static string ComputeComponentTypeNameHash(Type componentType)
{
    if (componentType.FullName is not { } typeName)
    {
        throw new InvalidOperationException($"An invalid component type was used.");
    }

    var typeNameLength = typeName.Length;
    var typeNameBytes = typeNameLength < 1024
        ? stackalloc byte[typeNameLength]
        : new byte[typeNameLength];

    Encoding.UTF8.GetBytes(typeName, typeNameBytes);

    Span<byte> typeNameHashBytes = stackalloc byte[SHA1.HashSizeInBytes];
    SHA1.HashData(typeNameBytes, typeNameHashBytes);

    return Convert.ToHexString(typeNameHashBytes);
}

class こんにちは
{

}

Exceptions (if any)

This will produce a System.ArgumentException since the destination buffer is too small.

.NET Version

No response

Anything else?

Please feel free to close this issue if the type in ComputeComponentTypeNameHash is not exposed to developers.

[vcsjones]

If this is indeed a but then I would propose the change look something like this:

static string ComputeComponentTypeNameHash(Type componentType)
{
    if (componentType.FullName is not { } typeName)
    {
        throw new InvalidOperationException($"An invalid component type was used.");
    }

    const int MaxStackBuffer = 1024;
    var maxTypeNameLength = Encoding.UTF8.GetMaxByteCount(typeName.Length);
    var typeNameBytes = maxTypeNameLength <= MaxStackBuffer
        ? stackalloc byte[MaxStackBuffer]
        : new byte[maxTypeNameLength];

    int written = Encoding.UTF8.GetBytes(typeName, typeNameBytes);

    Span<byte> typeNameHashBytes = stackalloc byte[SHA1.HashSizeInBytes];
    SHA1.HashData(typeNameBytes[..written], typeNameHashBytes);

    return Convert.ToHexString(typeNameHashBytes);
}

If you are targeting .NET 8 you can write this, which will have better performance for the "full type name is not more than 1024 bytes" case which seems typical.

static string ComputeComponentTypeNameHash(Type componentType)
{
    if (componentType.FullName is not { } typeName)
    {
        throw new InvalidOperationException($"An invalid component type was used.");
    }

    Span<byte> typeNameBytes = stackalloc byte[1024];
    int written;

    if (!Encoding.UTF8.TryGetBytes(typeName, typeNameBytes, out written))
    {
        typeNameBytes = Encoding.UTF8.GetBytes(typeName);
        written = typeNameBytes.Length;
    }
    Span<byte> typeNameHashBytes = stackalloc byte[SHA1.HashSizeInBytes];
    SHA1.HashData(typeNameBytes[..written], typeNameHashBytes);

    return Convert.ToHexString(typeNameHashBytes);
}

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.