search

aws-powertools / powertools-lambda-dotnet

Powertools is a developer toolkit to implement Serverless best practices and increase developer velocity.
https://docs.powertools.aws.dev/lambda/dotnet/
MIT No Attribution
152 stars 24 forks source link

Feature request: Sign the assemblies in the PowerTools packages. #597

Closed ddoti closed 2 months ago

ddoti commented 3 months ago

Use case

We are building libraries that leverage some of the AWS Powertools packages to help with the transition to AWS. As part of our best practices, our libraries are signed to ensure they are cannot be tampered by an outside party. We have other protections to help prevent us from pulling down packages from an untrusted source. However, signing the assembly just adds that additional layer of protection.

Solution/User Experience

The solution to this would be to sign the assemblies that are published in the AWS Powertools packages.

https://learn.microsoft.com/en-us/visualstudio/ide/managing-assembly-and-manifest-signing?view=vs-2022

Anything that was referencing packages with unsigned assemblies will not break when upgrading to assemblies that are signed.

Alternative solutions

No response

Acknowledgment

boring-cyborg[bot] commented 3 months ago

Thanks for opening your first issue here! We'll come back to you as soon as we can. In the meantime, check out the #dotnet channel on our Powertools for AWS Lambda Discord: Invite link

hjgraca commented 3 months ago

Hey @ddoti thanks for raising the issue. We do in fact sign all our DLLs as you can see from the image bellow when opening the Logging DLL

image
ddoti commented 3 months ago

When packaging my library, or when packaging a signed lambda I get the following warnings:

... publish: CSC : warning CS8002: Referenced assembly 'AWS.Lambda.Powertools.Tracing, Version=1.4.2.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.
... publish: CSC : warning CS8002: Referenced assembly 'AWS.Lambda.Powertools.Logging, Version=1.5.1.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.
... publish: CSC : warning CS8002: Referenced assembly 'AWS.Lambda.Powertools.Metrics, Version=1.6.1.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

Which then fails when it is signing the top level assembly. I would assume that if these assemblies were being signed it would have a PublicKeyToken that would be used for validating the assembly isn't tampered with.

hjgraca commented 3 months ago

Hey @ddoti thanks for providing more info. Let me refer back to the .NET documentation and why we only sign the DLLs but do not create strong naming. https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

Let me point out some quotes from the docs:

Strong naming has no benefits on .NET Core/5+. C# compiler produces CS8002 warning for strong-named assemblies referencing non-strong named assemblies. It is fine to suppress this warning for libraries that target .NET Core/5+ only.

We are only targeting .NET 6 and .NET 8, strong naming is recommended only on previous versions or full .NET framework. It is safe to supres that warning.

You should strong name your open-source .NET libraries if their targets include .NET Framework or .NET Standard. Strong naming is not required for libraries that target .NET Core/5+ only.

Contrary opinion contested by the .NET team on this issue https://github.com/dotnet/docs/issues/22412

We saw strong naming creating many problems, and having diminishing value in .NET Core. We wanted problems with strong naming to go away in .NET Core. Ignoring strong names for binding was a part of the plan to achieve that.

And regarding security more info on the docs https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named

image

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.

Hope this helps