[🚀 Feature]: Publish StrongNamed builds to nuget feed

[harunurhan]

Feature and motivation

It would make it easier to consume if strong name signed versions of the packages, such as Selenium.WebDriver.StrongNamed were published to nuget.org feed, currently it's only possible to download from github.

Usage example

N/A

[github-actions]

@harunurhan, 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!

[nvborisenko]

I don't think we will publish it in nuget feed. More realistic scenario is making Selenium.WebDriver with strong name.

[Mek7]

OK, it would be very useful also for us. Any news on this?

[superbull]

Hi, when will the strong named version published in nuget feed?

[nvborisenko]

Only with Selenium 5 as a major breaking change, and if core team doesn't mind.

[Mek7]

Major breaking change?
Strongly naming a library doesn't influence existing consumers, only broadens its usability for environments where everything is strongly named (and thus, non-strongly named libraries cannot be referenced).
Am I missing something?

[tbremard]

Hello,
I can see that this ticket is open since 1 year (july 2023 when we are in june 2024.
I did not see it and created this ticket (which has been closed because of 'duplication'):
#14115

let me copy paste my last comment:

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 that my own project is referencing 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

I think in the back lines this is more an issue about knowledge of how strong name signing works rather than a technical blocker.

[nvborisenko]

I feel Selenium 5 will be signed with strong name. Technically we are ready to do it, I don't see any reasons why the assembly cannot be signed in, build process is adopted.

Why not now?.. Because it is breaking change at binary level, all users who consume the assembly transitively will be affected. Given that this assembly is still not signed yet for a long time, and the source code is opened for everybody, I can summarize - wait major update v5 or apply one of many workarounds available to you. Signing the assembly right now will damage the project more than hilling.

[tbremard]

Thank you I would be happy to learn about a scenario which would show an issue if you release tomorrow a strong named version. I would like to know which one with the parameters for my curiosity. Le mer. 12 juin 2024 à 16:37, Nikolay Borisenko ***@***.***> a écrit :

…

I feel Selenium 5 will be signed with strong name. Technically we are ready to do it, I don't see any reasons why the assembly cannot be signed in, build process is adopted. Why not now?.. Because it is breaking change at binary level, all users who consume the assembly transitively will be affected. Given that this assembly is still not signed yet for a long time, and the source code is opened for everybody, I can summarize - wait major update v5 or apply one of many workarounds available to you. Signing the assembly right now will damage the project more than hilling. — Reply to this email directly, view it on GitHub <#12315 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIULZZD345MRUWMDXDRUDCLZHBMJ7AVCNFSM6AAAAAAZ7FAD2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGE4DGMBTHE> . You are receiving this because you commented.Message ID: ***@***.***>

[nvborisenko]

Releasing new signature of the assembly will not break you, but it will break me, my friend and friend of my friend. Read more https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming, with attention on what Microsoft recommends when the assembly signature is changing. I care about my friend and his friend more than you, because 2 is greater than 1.

[tbremard]

Thank you Nikolay for your prompt reply, but your answer "friend of friend" is not a technical explanation. regarding your link I read: "You should strong name your open-source .NET libraries if their targets include .NET Framework or .NET Standard. " Regards

…

-------------------------------- Thierry Brémard ***@***.*** Le mer. 12 juin 2024 à 16:56, Nikolay Borisenko ***@***.***> a écrit :

Releasing new signature of the assembly will not break you, but it will break me, my friend and friend of my friend. Read more https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming, with attention on what Microsoft recommends when the assembly signature is changing. I care about my friend and his friend more than you, because 2 is greater than 1. — Reply to this email directly, view it on GitHub <#12315 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIULZZCGTHYEAIUFBV7QSQLZHBOTTAVCNFSM6AAAAAAZ7FAD2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGI2TMOBXG4> . You are receiving this because you commented.Message ID: ***@***.***>

[nvborisenko]

Thanks for your curiosity, I already said that is a breaking change at binary level. Googling it is more useful than I try to explain the problem here. I used "friend of friend" to highlight that you are not alone, and making changes is not a safe process.

…

On Wed, Jun 12, 2024, 6:16 PM Thierry Bremard ***@***.***> wrote: Thank you Nikolay for your prompt reply, but your answer "friend of friend" is not a technical explanation. regarding your link I read: "You should strong name your open-source .NET libraries if their targets include .NET Framework or .NET Standard. " Regards -------------------------------- Thierry Brémard ***@***.*** Le mer. 12 juin 2024 à 16:56, Nikolay Borisenko ***@***.***> a écrit : > Releasing new signature of the assembly will not break you, but it will > break me, my friend and friend of my friend. Read more > https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming, > with attention on what Microsoft recommends when the assembly signature is > changing. I care about my friend and his friend more than you, because 2 is > greater than 1. > > — > Reply to this email directly, view it on GitHub > < #12315 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AIULZZCGTHYEAIUFBV7QSQLZHBOTTAVCNFSM6AAAAAAZ7FAD2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGI2TMOBXG4> > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#12315 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFMRXHXFWS6K5S5F4JXCMITZHBQ6FAVCNFSM6AAAAAAZ7FAD2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGMYDCNBVGA> . You are receiving this because you commented.Message ID: ***@***.***>

[tbremard]

Hello, ** I am aware that I challenge you. And that it might be not comfortable.** I take note that you are unable to describe any scenario where a user would be impacted by a new version of Selenium which would be strongly signed. Asking me to google it is a non sense as I already wrote that this would have no impact. If you disagree, engineer practice is to state a user story with precise terms where you spot an issue. Telling me that the binary would be changed is not a valid one as you do not state the client code would broke, and indeed if i release the same source code at 1 minute interval the binary would be different and even more different if the minor version number is incremented. By the way speaking about a **major version** (v4 to v5) change to release strong named key is also a non sense as this issue is now open about a year, It would give more sense to write an approximate release date eg august 2024. I tried to change your mind by using rational decision process, but it clearly looks there is other thing in your input. Regards

…

-------------------------------- Thierry Brémard ***@***.*** Le mer. 12 juin 2024 à 17:27, Nikolay Borisenko ***@***.***> a écrit :

Thanks for your curiosity, I already said that is a breaking change at binary level. Googling it is more useful than I try to explain the problem here. I used "friend of friend" to highlight that you are not alone, and making changes is not a safe process. On Wed, Jun 12, 2024, 6:16 PM Thierry Bremard ***@***.***> wrote: > Thank you Nikolay for your prompt reply, > but your answer "friend of friend" is not a technical explanation. > > regarding your link I read: > "You should strong name your open-source .NET libraries if their targets > include .NET Framework or .NET Standard. " > > > > Regards > > -------------------------------- > Thierry Brémard > ***@***.*** > > > Le mer. 12 juin 2024 à 16:56, Nikolay Borisenko ***@***.***> > a écrit : > > > Releasing new signature of the assembly will not break you, but it will > > break me, my friend and friend of my friend. Read more > > > https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming, > > > with attention on what Microsoft recommends when the assembly signature > is > > changing. I care about my friend and his friend more than you, because 2 > is > > greater than 1. > > > > — > > Reply to this email directly, view it on GitHub > > < > #12315 (comment)>, > > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AIULZZCGTHYEAIUFBV7QSQLZHBOTTAVCNFSM6AAAAAAZ7FAD2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGI2TMOBXG4> > > > . > > You are receiving this because you commented.Message ID: > > ***@***.***> > > > > — > Reply to this email directly, view it on GitHub > < #12315 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AFMRXHXFWS6K5S5F4JXCMITZHBQ6FAVCNFSM6AAAAAAZ7FAD2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGMYDCNBVGA> > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#12315 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIULZZCSZ24KFWEGANLUURDZHBSHDAVCNFSM6AAAAAAZ7FAD2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGMZDKOJTGM> . You are receiving this because you commented.Message ID: ***@***.***>

[nvborisenko]

Sorry, I am writing from mobile phone, without detailed explanation. You are still referring to compile time breaking change... there are no breaking changes. I am saying about changes at binary level. Just read more about it.

Scenarios? All transitive dependencies. Let's say my project is dependent on some package, which is dependent on selenium. Nobody stops me to upgrade to the latest selenium (why not, I really want to use the latest). And the problem comes in here, I will get an exception in runtime something about "cannot load assembly or its dependency".

[tbremard]

Thank you Nikolay,
You speak about referencing Selenium 'latest', which generates binaries with a constant "AssemblyIdentity" for the different versions 4.x.x.x as all releases are in fact technically tagged as 4.0.0.0.
The Assembly Identity contains also the "PublicKeyToken" . Hence currently you can swap your dll files between different minor versions (eg 4.10.0.0 to 4.20.0.0) as they will share same Assembly identity: "4.0.0.0 PubicKeyToken=null" without the need to rebuild your solutions which are using Selenium.

If a new minor version introduces a PublicKey token it will change the "AssemblyIdentity to 4.30.0.0 PublicKeyToken=xxxxx" hence current binariess will not be able anymore to load the new versions as the assembly Identity will be different. Thats why you want to do it in a "breaking release where major version number will be also updated to v5"

Thank you for this explanations.

[github-actions]

This issue is stale because it has been open 280 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stalled for 14 days with no activity.