search

Keeper-Security / secrets-manager

Keeper Secrets Manager is a cloud-based, zero-knowledge platform for securing infrastructure secrets. Provides automatic password rotation and integration into popular DevOps CI/CD tools.
https://www.keepersecurity.com/secrets-manager.html
MIT License
81 stars 46 forks source link

.NET SDK is not strong named. #404

Open danielwspie opened 1 year ago

danielwspie commented 1 year ago

We have a library of .NET Framework 4.7.2 assemblies that require referenced assemblies be strong named, thus including the NuGet package Keeper.SecretsManager Version 16.4.0 results in the following error:

System.IO.FileLoadException: 'Could not load file or assembly 'SecretsManager, Version=16.4.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required.

Based on this Microsoft documentation from Sept 2021, it recommends You should strong name your open-source .NET libraries. Strong naming an assembly ensures the most people can use it, and strict assembly loading only affects .NET Framework.. https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

Please consider strong naming your .NET SDK assemblies.

DevOma75 commented 1 year ago

I have signed the file in my build process but also would like to get a strong named file from Nuget package without manual steps

maksimu commented 3 months ago

Is there still a need for this? We are trying to decide if we should do this or not.

danielwspie commented 3 months ago

@maksimu yes, due to third party dependencies, we will be on this .NET Framework 4.7.2 infrastructure for the foreseeable future, so the inclusion of this will make our interaction with the Keeper library a much easier experience. Also note, this is the only NuGet package we've encountered that isn't strongly named.

maksimu commented 3 months ago

Ok one quick question then, should we publish a new one with a slightly different name ( append “.strongName “ for example), or just have one library published that is strong named. Will it break customers applications that are using our SDKs. Will our strong named application be like a “poison pill”?

On Thu, Mar 28, 2024 at 8:39 AM Daniel Watkins @.***> wrote:

@maksimu https://github.com/maksimu yes, due to third party dependencies, we will be on this .NET Framework 4.7.2 infrastructure for the foreseeable future, so the inclusion of this will make our interaction with the Keeper library a much easier experience. Also note, this is the only NuGet package we've encountered that isn't strongly named.

— Reply to this email directly, view it on GitHub https://github.com/Keeper-Security/secrets-manager/issues/404#issuecomment-2025523341, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABNXKT6L6A2IVFLLPTJ4L3Y2Q2TXAVCNFSM6AAAAAAUB2K4LWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRVGUZDGMZUGE . You are receiving this because you were mentioned.Message ID: @.***>

DevOma75 commented 3 months ago

One library is enough - as it is possible to reference signed assemblies from unsigned projects - the change will not affect anyone who used it in that way. But for all who are working with signed libraries it will be more comfortable - I have to use ildasm and ilasm in my build process to sign the assembly before referencing. That step would not be needed after you sign the assembly in NuGet package - thanks