Fix typo in managed port of strong name validation

[jkotas]

Fixes #66545

[jkotas]

@VSadov This is a bug in the managed port of AssemblyName. It is affecting all runtimes now that we have switched to managed implementation of the AssemblyName everywhere.

I was actually thinking about deleting this strong name key validation instead. It is useless in CoreCLR. CoreCLR can treat the strong name key as opaque blob. What do you think?

[VSadov]

I was actually thinking about deleting this strong name key validation instead. It is useless in CoreCLR. CoreCLR can treat the strong name key as opaque blob. What do you think?

The validation does not seem to be very expensive. We basically sanity-check the size and hash/alg IDs.
My concern is that once we relax the validation, more cases will become valid and may potentially break some tool or whatever took dependency on these constraints that we check now.
If there is not a lot to gain by relaxing, but there is some, even though low, probability of breaking, maybe we should just keep it?

[VSadov]

LGTM. Thanks!

[jkotas]

@VSadov Have you just created the area-runtime label? The issue automation expects to have all area- labels associated with owners in https://github.com/dotnet/runtime/blob/main/docs/area-owners.md .

[jkotas]

All failures are timeouts. Helix running out of capacity?

[teo-tsirpanis]

FYI area-runtime came from issues transferred from ASP.NET Core. (#62032 (comment))

[VSadov]

Yes. I could not place this in a particular runtime, since this is in a shared component (so not strictly coreclr or mono or NativeAOT), then I noticed area-runtime and used it. It was already in the list.