khellang
commented
4 months ago However, the signing key must not be public. Currently, anyone can grab your signing key and sign their own assembly
That's the entire point. This is an open source project. Anyone should be able to build it for themselves. From the Microsoft docs:
If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.
defeating the whole purpose of strong naming: the idea is to prevent code injection in sensitive scenarios where anyone could grab your code, inject their own malicious code, compile it and replace a valid assembly somewhere with the hacked one.
I think you've misunderstood the purpose of strong naming. It's not a security feature, but an identity feature. See Microsoft docs:
Do not rely on strong names for security. They provide a unique identity only.
I want to make the case that it's preferable to not sign the assembly at all if the key is public/leaked, otherwise people might trust that this is a secure assembly where, in fact, it isn't.
I agree, but for entirely different reasons 😆
I see from #53 that Scrutor only added Strong Naming because a different package wanted it. However, the signing key must not be public. Currently, anyone can grab your signing key and sign their own assembly, defeating the whole purpose of strong naming: the idea is to prevent code injection in sensitive scenarios where anyone could grab your code, inject their own malicious code, compile it and replace a valid assembly somewhere with the hacked one.
I want to make the case that it's preferable to not sign the assembly at all if the key is public/leaked, otherwise people might trust that this is a secure assembly where, in fact, it isn't.
I'll also create a similar issue in Swashbuckle.AspNetCore.Filters.