search

mattfrear / Swashbuckle.AspNetCore.Filters

A bunch of useful filters for Swashbuckle.AspNetCore
MIT License
431 stars 80 forks source link

Signing key shouldn't be public #251

Closed bruno-brant closed 4 months ago

bruno-brant commented 4 months ago

Signing keys 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 (or even the assembly directly), inject their own malicious code, compile and sign it, then 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 when, in fact, it isn't.

mattfrear commented 4 months ago

Oh, oops, thanks for pointing that out.

Honestly, I didn't care for strong naming it, but some random guy asked for it because of his corporate policy, so I did it.

What should I do now? Should I create another key but not expose it this time? Or is it too late?

bruno-brant commented 4 months ago

Sorry Matt, it was just pointed out to me that this is no longer the guidance from msft. The key can be public and checked in.

I'll close the issue, but thanks for taking the time to read it.

Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: Matt Frear @.> Sent: Monday, July 1, 2024 6:37:19 PM To: mattfrear/Swashbuckle.AspNetCore.Filters @.> Cc: Author @.***> Subject: Re: [mattfrear/Swashbuckle.AspNetCore.Filters] Signing key shouldn't be public (Issue #251)

Oh, oops, thanks for pointing that out.

Honestly, I didn't care for strong naming it, but some random guy asked for it because of his corporate policy, so I did it.

What should I do now? Should I create another key but not expose it this time? Or is it too late?

— Reply to this email directly, view it on GitHubhttps://github.com/mattfrear/Swashbuckle.AspNetCore.Filters/issues/251#issuecomment-2201115562 or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAONUVATYUL236O5ONXRP5LZKHDY7BFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOJIFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVA4DSOJVGEZDKNECUR2HS4DFUVUXG43VMWSXMYLMOVS2UMRTHAZTOMZXGMYDRJ3UOJUWOZ3FOKTGG4TFMF2GK. You are receiving this email because you authored the thread.

Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

mattfrear commented 4 months ago

OK. Before you close the issue, please add a link to the MSFT reference docs you're referring to.

bruno-brant commented 4 months ago

Here it is: https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named

The sole purpose is to avoid name clashes.

mattfrear commented 4 months ago

Thanks for the link. Interesting.

Do not rely on strong names for security. They provide a unique identity only. For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.

Sounds like a waste of time then, since this package is .NET Core only.