[CSHARP-1276] Provide Strong-Named Assemblies Created: 12/May/15  Updated: 20/Dec/22

Status: Backlog
Project: C# Driver
Component/s: Build
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Anil Kumar Assignee: Unassigned
Resolution: Unresolved Votes: 11
Labels: size-medium
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by CSHARP-3571 Strong name issues Closed
is duplicated by CSHARP-1835 There is no strongly named version of... Closed
is duplicated by CSHARP-4418 Add strong name to MongoDB.Driver and... Closed
Related
is related to CSHARP-1835 There is no strongly named version of... Closed
Quarter: FY24Q1
Case:

 Description   

Certain users require the use of strongly-named assemblies. While strongly-named assemblies can cause major problems and headaches, certain shops are forced to work with them. To make it easier and not require them to do self-signing, we should provide strongly-named assemblies in addition to the non-signed versions we currently deploy.

For Reference:



 Comments   
Comment by James Kovacs [ 13/Dec/22 ]

Thanks for checking in. We removed strong naming in CSHARP-616 (version 2.0.0) because of bad user experiences with strong naming. The .NET landscape has changed substantially in the intervening years and current guidance from Microsoft recommends providing strong names for assemblies. Of particular note:

The downside to strong naming is that .NET Framework on Windows enables strict loading of assemblies once an assembly is strong named. A strong-named assembly reference must exactly match the version of the loaded assembly, forcing developers to configure binding redirects when using the assembly:
… assembly binding redirect example …
When .NET developers complain about strong naming, what they’re usually complaining about is strict assembly loading. Fortunately, this issue is isolated to .NET Framework. .NET 5+, .NET Core, Xamarin, UWP, and most other .NET implementations don’t have strict assembly loading, which is the main downside of strong naming.

Having done some investigation and testing, we plan to schedule this issue for early in the new year.

Comment by Cv Join [ 12/Dec/22 ]

Hi James

Any plan to implement this, half year passed, since the last conversation.

Fei

Comment by Donald Gathman [ 23/May/22 ]

Hi James,

Great info, thanks a bunch for your reply and consideration.

--Don

 

Comment by James Kovacs [ 20/May/22 ]

Hi, don.gathman@hp.com,

Thank you for your feedback. We made the explicit choice not to sign our assemblies due to the pain encountered by users due to assembly version mismatches between dependent libraries and the unwieldiness of assembly binding redirects. A lot has changed in the .NET ecosystem in the last 7 years and we are going to reconsider our policy of not strong naming our assemblies.

Note that strong naming is about assembly identity and not security. In fact Microsoft recommends that open source projects commit their public/private strong name keys to their public repositories:

>✔️ CONSIDER adding the strong naming key to your source control system.
– from Strong Naming Guidance in MSDN

We have a separate task to code sign our NuGet packages (see CSHARP-3471), which would provide assurances of NuGet package authenticity.

In summary we plan to re-examine our reasons for not strong naming our assemblies and may start strong naming our assemblies in an upcoming release. Please follow this ticket for updates on our investigations and decisions.

Sincerely,
James

Comment by Donald Gathman [ 20/May/22 ]

Looks like this request has been in the system for 7 years. Most of my team was shocked that MongoDB doesn't sign dll's that it provides to customers.  We'd really like to see this get some traction!

Comment by Jeffrey Yemin [ 02/Apr/21 ]

See https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming for Microsoft recommendations. In short, it's recommended best practice for public libraries.

Generated at Wed Feb 07 21:39:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.