Open 3F opened 2 years ago
Starting with 187f0e9, you can define the following:
MvsSlnFeatureHuid=true
to enable implementation on HuidMvsSlnFeatureGuidSha1=true
to use Sha-1 based hashing (edition for DllExport up to 1.7.4)Note:
Huid (Fnv-1a-128 (via LX4Cnh)) and Sha-1 hashing works in Guids.domainMvsSln (the base), while implementation on MD5 uses initial vector.
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 👇
! MvsSln doesn't use any weak algorithms (md5, Fnv1a, LX4Cnh, sha1, ...) for security related purposes. Only for UUID related things.
MvsSlnFeatureHuid
via AdditionalProperties in ProjectReference may cause problems
<ProjectReference Include="...MvsSln.csproj">
...
<AdditionalProperties>MvsSlnFeatureHuid=true</AdditionalProperties>
because we're using a common.props
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.