Major changing for Guid (UUID) core processing. Moving up to Fnv-1a-128 based algorithms

[3F]

Here, I was saying about Huid (-> Fnv-1a-128 (-> LX4Cnh)) which provides related fastest generating UUID in a .NET System.Guid compatible manner.

Today's MvsSln relies on MD5 (or SHA-1, edition for DllExport) when generating and comparing something from strings using Guid.

For example, XProject.PId and related Guid-like hashing

https://github.com/3F/MvsSln/blob/2cc2dd820dd4dc49c1072597d446ecc7575a7abd/MvsSln/Core/XProject.cs#L752-L766

This, of course, should not affect any well known Guids for VS/msbuild support. Only parts where must be generating a new one from input string. However, this invalidates the previously generated values which may require a complete re-evaluation in some cases.

Please feedback if this upgrading may cause problems and cannot be adapted in some used infrastructure etc.

[3F]

Starting with 187f0e9, you can define the following:

• MvsSlnFeatureHuid=true to enable implementation on Huid
• MvsSlnFeatureGuidSha1=true to use Sha-1 based hashing (edition for DllExport up to 1.7.4)

Note:

1. Huid (Fnv-1a-128 (via LX4Cnh)) and Sha-1 hashing works in Guids.domainMvsSln (the base), while implementation on MD5 uses initial vector.

2. Remember, the default md5 for MvsSln 2.x is not FIPS compliant (according to the use of the System.Security.Cryptography implementation) and can cause the problems like this. I won't re-implement md5 beyond System.Security.Cryptography because 👇

3. ! MvsSln doesn't use any weak algorithms (md5, Fnv1a, LX4Cnh, sha1, ...) for security related purposes. Only for UUID related things.

4. MvsSlnFeatureHuid via AdditionalProperties in ProjectReference may cause problems

<ProjectReference Include="...MvsSln.csproj">
    ...
  <AdditionalProperties>MvsSlnFeatureHuid=true</AdditionalProperties>

because we're using a common.props