[🐛 Bug]: Strong Name Key

[tbremard]

What happened?

After upgrade to last version of selenium Selenium.WebDriver.4.21.0:

Historical issue has not been solved: https://github.com/SeleniumHQ/selenium/issues/10069

Current issue: When Signed binary is used it fails at loading Selenium dependency because Strong Name is transitive : if a binary is signed all dependencies must be signed otherwise there is loading error:

To solve this issue: edit project properties in visual studio/signing/generate a snk file:

How can we reproduce the issue?

At build time this message happens:

21>CSC : warning CS8002: Referenced assembly 'WebDriver, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.
21>CSC : warning CS8002: Referenced assembly 'Appium.Net, Version=5.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

Execution:
Could not load file or assembly 'WebDriver, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)

Relevant log output

Could not load file or assembly 'WebDriver, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)

Operating System

Windows 10

Selenium version

Selenium.WebDriver.4.21.0

What are the browser(s) and version(s) where you see this issue?

none : this is client driver issue at loading

What are the browser driver(s) and version(s) where you see this issue?

none : this is client driver issue at loading

Are you using Selenium Grid?

no

[github-actions[bot]]

@tbremard, thank you for creating this issue. We will troubleshoot it as soon as we can.

---

Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

[titusfortner]

You can find the strongnamed packages in the github release assets: https://github.com/seleniumhq/selenium/releases/latest

[tbremard]

Thank you but strongly named should be embedded 8n default nuget package as it is needed for auto rebuild. I do not see the point to release not signed binaries

Le mar. 11 juin 2024 à 17:40, Titus Fortner @.***> a écrit :

You can find the strongnamed packages in the github release assets: https://github.com/seleniumhq/selenium/releases/latest

— Reply to this email directly, view it on GitHub https://github.com/SeleniumHQ/selenium/issues/14115#issuecomment-2161075454, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIULZZF33IOPOFLT3XKCKNDZG4K5VAVCNFSM6AAAAABJCLQSGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRRGA3TKNBVGQ . You are receiving this because you were mentioned.Message ID: @.***>

[titusfortner]

I'm not a .NET expert here, but if we release strong named only, then all projects that have Selenium as a dependency will also need to release strong named, version management will be even harder, and it will not be backwards compatible.

@jimevans / @nvborisenko is the right compromise here to start publishing Selenium.WebDriver.StrongNamed on Nuget? We're already generating it, but distributing it in a different place does make discoverability harder.

[tbremard]

I am dot net expert. This is the opposite: any non signed program can use any deps whether signed or non signed.

Signed program can only use signed dependencies so if I want to sign my code I cannot do it because your dll is not protected.

Look at your dependencies by browsing signature like I added in screenshot you should see signed deps eg nlog.

Le mar. 11 juin 2024 à 18:19, Titus Fortner @.***> a écrit :

I'm not a .NET expert here, but if we release strong named only, then all projects that have Selenium as a dependency will also need to release strong named, version management will be even harder, and it will not be backwards compatible.

@jimevans https://github.com/jimevans / @nvborisenko https://github.com/nvborisenko is the right compromise here to start publishing Selenium.WebDriver.StrongNamed on Nuget? We're already generating it, but distributing it in a different place does make discoverability harder.

— Reply to this email directly, view it on GitHub https://github.com/SeleniumHQ/selenium/issues/14115#issuecomment-2161153231, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIULZZBU2UDUZQE2222SESLZG4PQ7AVCNFSM6AAAAABJCLQSGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRRGE2TGMRTGE . You are receiving this because you were mentioned.Message ID: @.***>

[nvborisenko]

Duplicate of #12315

[tbremard]

This not a breaking change. But the contrary, as you enable more aps to use it

Le mar. 11 juin 2024 à 22:29, Nikolay Borisenko @.***> a écrit :

Duplicate of #12315 https://github.com/SeleniumHQ/selenium/issues/12315

— Reply to this email directly, view it on GitHub https://github.com/SeleniumHQ/selenium/issues/14115#issuecomment-2161555297, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIULZZE4DU5RXYU463IM6WTZG5M2RAVCNFSM6AAAAABJCLQSGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRRGU2TKMRZG4 . You are receiving this because you were mentioned.Message ID: @.***>

[titusfortner]

Either way, we can continue the discussion on that issue

[tbremard]

Thank you titus, I see that the request is closed and do not understand why.

Strong-naming an assembly introduces a small initial overhead, as it requires generating a key pair and integrating the signing process into the build pipeline. However, once this key pair is generated, it can be reused for all subsequent releases, making the process transparent and straightforward for future updates.

For a widely used library like Selenium, providing strong-named assemblies in the NuGet package would enable developers to use these assemblies in environments that require strong-naming, such as in large enterprises with strict security policies. It allows these developers to maintain strong-naming across their entire application stack, ensuring compatibility and compliance with their security requirements.

Moreover, it is worth noting that most NuGet packages available today include a public key, which means they are already strong-named. This has become a standard practice, reflecting the industry's emphasis on security and integrity. By aligning with this standard, the Selenium library will not only enhance its security posture but also meet the expectations of its user base, facilitating smoother integration and wider adoption.

The benefits of strong-named assemblies in promoting security, integrity, and trustworthiness far outweigh the small initial overhead. Incorporating strong-named assemblies in the next minor release would significantly enhance the utility of the Selenium library, making it more suitable for a wider range of applications and increasing its adoption in secure and enterprise environments. Furthermore, it is important to consider the principle of transitivity in strong-naming. A non-signed project can use both non-signed and signed assemblies without issue. However, if a project requires a strong-named assembly, it cannot use a non-signed assembly, as it will be refused to load at runtime. By adding strong-naming to the Selenium NuGet package, you significantly increase the potential user base, as both non-signed and signed projects will be able to integrate Selenium seamlessly. This inclusivity broadens the ecosystem of users who can rely on Selenium for their testing needs, enhancing the library's adoption and utility across various environments and security requirements.

Of course, while you currently provide signed assemblies in a zip file, however best practices in modern .NET development strongly recommend using NuGet package references rather than hard-copied DLL files. NuGet packages ensure better dependency management, automatic updates, and a more streamlined development process. Including strong-named assemblies directly in the NuGet package would align with these best practices, making it easier and more efficient for developers to integrate Selenium into their projects. I invite you to look at your own dotnet dependencies, browse the method declarations and see at the top of each of your dependencies a public key token, like the ones which follow:

region Assembly System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

// C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.8\System.Windows.Forms.dll

endregion

region Assembly System.Xml.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

// C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.8\System.Xml.Linq.dll

endregion

region Assembly DevExpress.RichEdit.v13.1.Core, Version=13.1.8.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a

region Assembly NLog, Version=5.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c

Find the exception....

region Assembly WebDriver, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null

// C:\Work\GitlabRepos\TechTest.Taf\packages\Selenium.WebDriver.4.21.0\lib\netstandard2.0\WebDriver.dll

endregion

[diemol]

It is closed because there is already an issue for this, see #12315 The conversation can continue there.