How to Sign the assembly with a strong name about flashcap

[kekyo]

Thanks for using FlashCap!

FlashCap does not have Strong name applied, but if you need:

• Clone the repository and build the project yourself. At that time, modify the project slightly to apply the Strong name.
• Extract the assemblies you need from the NuGet package and apply the Strong name directly. Apparently this can't be done....

I understand that these methods are tedious ¯\_(ツ)_/¯

However, I do not intend to apply strong name to FlashCap at this time. When considered in the context of security assurance, we view the application of strong names as a security technique of the past. If you want to ensure security, I recommend using code signing certificates instead of strong names:

• Reference: https://learn.microsoft.com/en-us/dotnet/standard/assembly/security-considerations

If you are building a program as an in-house system and it is a problem with your in-house managed Defender, I would suggest that you share with your team that such a policy is nonsense. On the other hand, if it is simply a problem that is occurring with an application that you are personally building, you could, for example, add the build directory to Defender's exclusion rules.

(If Defender is referring to Windows Defender, there may be some other factor, since the problem is not occurring in my environment.)

Now here's why I'm ignoring Strong name. I have some other personal questions for myself:

• Handling of signature keys, as you can see if you look for OSS projects that apply Strong name.
  As you can see when you look for projects that apply Strong name to OSS projects, private keys that should be covered up are often placed in the OSS project and published together.
  This technology is really ridiculous and shows that Strong name technology does not make any sense other than providing IDs.
• Maintaining CI is a pain; CI automates the build, but the bottleneck here is the management of the private key used to apply the Strong name. As mentioned above, this is one of the reasons why many OSS projects expose private keys.
• Here is a technical problem: It has an incomprehensible side effect on the assembly loading mechanism.
  For projects that rely on a large number of external assemblies, it is easy to have builds not pass due to mismatches between dependent versions. This would seem to work to ensure full compatibility. However, in modern .NET development, there are large numbers of assemblies that are resolved by NuGet.
  While many OSS are tolerant of version mismatches because they are maintained backward compatibility of the assembly's public interfaces. When an assembly with Strong name applied exists, the strictness of the version conformity causes a version mismatch error that is difficult for humans to understand. I have spent with this issue for a long time and have made the choice to abandon Strong name technology.

I forgot to mention that Microsoft has recently started applying digital signatures automatically to packages published from nuget.org. This does not mean that they will digitally sign the assembly, but I think they want it to serve as a source for us to verify the origin of the package. (There is some question as to whether it will work effectively...)

[kekyo]

It looks like there will probably be no additional information, so I will close it once. If there are any problems, please reopen.