New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

To Sign or not Sign all packages by default in v5 #548

Closed
mythz opened this Issue Jun 22, 2017 · 11 comments

Comments

Projects
None yet
5 participants
@mythz
Member

mythz commented Jun 22, 2017

Major releases are a window by which we make structural changes similar to how v4.5.x was when we upgraded all packages to .NET 4.5. The next major v5 release of ServiceStack is planned for shortly after Microsoft releases the stable (i.e. non-beta) release of .NET Core / .NET Standard v2.0.

The major changes for v5 currently include:

  • Upgrading to use v3 NuGet spec which allows specifying different dependencies for different builds
  • Merging the .NET Core packages into main packages so they follow the same release cadence as .NET 4.5 packages
  • Upgrade .NET Core packages to .NET Core 2 and .NET Standard 2 which looks like the first .NET Core version which will be stable and have longevity
  • Drop PCL and Silverlight builds in favor of .NET Standard
  • Remove all deprecated APIs (Except for OrmLite legacy deprecated APIs)

The other major change we're considering is whether to sign all packages following the same approach as we're doing with ServiceStack.Interfaces where we keep the AssemblyVersion fixed at 5.0.0.0 and use the AssemblyFileVersion to report the true version number.

We'd like to hear from the existing ServiceStack community on whether we should do sign all packages as we're against the friction of strong naming but we're leaning towards doing it as our ServiceStack.Interfaces approach hasn't seen any reported issues due to strong naming since we added it in v4, Strong naming isn't going away as we'd hoped (and looked like it was going to at one stage in .NET Core), we also like the simplicity of only having 1 NuGet package for all platforms that can be used in both Signed/non-Signed projects. If we do go with Strong naming by default we'll be publishing our Signing key so everyone can continue to create custom builds of ServiceStack.

Please add a thumbs up reaction if you'd like all v5 packages to be Signed and a thumbs down if you'd prefer to keep existing packages unsigned and retain Signed packages in .Signed NuGet packages.

Please also leave a comment if you have other specific reasons for wanting to keep packages unsigned.

@mythz mythz changed the title from To Sign or not Sign all packages by default to To Sign or not Sign all packages by default in v5 Jun 22, 2017

@advapiIT

This comment has been minimized.

Show comment
Hide comment
@advapiIT

advapiIT Jun 22, 2017

Excuse me Mythz, I've voted but was wondering what's the advantage of having them signed and to share the Signing key...

advapiIT commented Jun 22, 2017

Excuse me Mythz, I've voted but was wondering what's the advantage of having them signed and to share the Signing key...

@mythz

This comment has been minimized.

Show comment
Hide comment
@mythz

mythz Jun 22, 2017

Member

@advapiIT There's no change in behavior and functionality, it's just about whether we should consolidate ServiceStack and ServiceStack.Signed packages together. It may help reduce docs / support costs if needing to deal with external clients on whether they'd need to reference ServiceStack.Client or ServiceStack.Client.Signed packages.

But it would help Customers who need Strong named packages as they'd be able to make use of ServiceStack features like VS.NET Templates and IDE Add ServiceStack Reference integration which currently only adds references to the main (non-signed) NuGet packages.

Member

mythz commented Jun 22, 2017

@advapiIT There's no change in behavior and functionality, it's just about whether we should consolidate ServiceStack and ServiceStack.Signed packages together. It may help reduce docs / support costs if needing to deal with external clients on whether they'd need to reference ServiceStack.Client or ServiceStack.Client.Signed packages.

But it would help Customers who need Strong named packages as they'd be able to make use of ServiceStack features like VS.NET Templates and IDE Add ServiceStack Reference integration which currently only adds references to the main (non-signed) NuGet packages.

@Siliconrob

This comment has been minimized.

Show comment
Hide comment
@Siliconrob

Siliconrob Jun 22, 2017

Strong naming has always been a plague and a virus when someone asks to bring it in, infecting the entire codebase. Will this make it easy for someone to accidentally add a strong name reference?

Several times someone has put a mix of signed/unsigned dlls that is a pain to figure out which dependency fails in larger projects.

Siliconrob commented Jun 22, 2017

Strong naming has always been a plague and a virus when someone asks to bring it in, infecting the entire codebase. Will this make it easy for someone to accidentally add a strong name reference?

Several times someone has put a mix of signed/unsigned dlls that is a pain to figure out which dependency fails in larger projects.

@mythz

This comment has been minimized.

Show comment
Hide comment
@mythz

mythz Jun 22, 2017

Member

@Siliconrob Unsigned projects can reference Signed dlls, e.g. all Microsoft packages and popular 3rd Party packages like JSON.NET and AutoMapper are strong named. The issues are when you have different dependencies referencing different versions of Signed packages which can result in dll hell. But we're going to keep the AssemblyVersion fixed to 5.0.0.0 to do our best to avoid it.

The proposal here is whether all ServiceStack packages should be Signed in v5.

Member

mythz commented Jun 22, 2017

@Siliconrob Unsigned projects can reference Signed dlls, e.g. all Microsoft packages and popular 3rd Party packages like JSON.NET and AutoMapper are strong named. The issues are when you have different dependencies referencing different versions of Signed packages which can result in dll hell. But we're going to keep the AssemblyVersion fixed to 5.0.0.0 to do our best to avoid it.

The proposal here is whether all ServiceStack packages should be Signed in v5.

@Siliconrob

This comment has been minimized.

Show comment
Hide comment
@Siliconrob

Siliconrob Jun 22, 2017

I voted not to sign because of that explicit dll hell. You would keep the assembly fixed at 5 for all libraries seems like you forcing everyone to adopt the strong name peoples preferences and habits.

You stated above how you wanted to get rid of strong naming, but holdouts who are not comfortable signing their own packages for their own perverse reasons should be pointed to the availability of open source tools like so that allow you to sign whatever you want.

https://github.com/dsplaisted/strongnamer
https://github.com/brutaldev/StrongNameSigner

I understand this helps you with distribution channels and consolidating releases, but I think it is going the wrong way, dropping strong name support is what I think is best overall for .NET Core going forward. I mean the older .NET is lost on this because of legacy applications, but here you have a chance to make a clean break on strong naming.

Siliconrob commented Jun 22, 2017

I voted not to sign because of that explicit dll hell. You would keep the assembly fixed at 5 for all libraries seems like you forcing everyone to adopt the strong name peoples preferences and habits.

You stated above how you wanted to get rid of strong naming, but holdouts who are not comfortable signing their own packages for their own perverse reasons should be pointed to the availability of open source tools like so that allow you to sign whatever you want.

https://github.com/dsplaisted/strongnamer
https://github.com/brutaldev/StrongNameSigner

I understand this helps you with distribution channels and consolidating releases, but I think it is going the wrong way, dropping strong name support is what I think is best overall for .NET Core going forward. I mean the older .NET is lost on this because of legacy applications, but here you have a chance to make a clean break on strong naming.

@mythz

This comment has been minimized.

Show comment
Hide comment
@mythz

mythz Jun 22, 2017

Member

@Siliconrob The decision of whether .NET Core should drop Strong named support is long over, .NET Core and .NET will be supporting Strong naming forever.

You would keep the assembly fixed at 5 for all libraries seems like you forcing everyone to adopt the strong name peoples preferences and habits.

It's very common place to keep signed dlls at a constant major Assembly Version which we've been doing since 2013 with ServiceStack.Interfaces (and all our .Signed packages).

I understand this helps you with distribution channels and consolidating releases

We've already got the infrastructure in place to support creating .Signed packages, it's about simplicity, maximum utility of a single set of packages which will reduce docs and make life easier for developers who need to use strong named packages for whatever reason which looks like is over 20% of downloads. They currently have a sub-par experience who have to put in additional effort to get ServiceStack features work for their projects.

but I think it is going the wrong way, dropping strong name support is what I think is best overall for .NET Core going forward. I mean the older .NET is lost on this because of legacy applications, but here you have a chance to make a clean break on strong naming.

ServiceStack not signing packages has no influence on whether .NET Core will drop strong named support - that's over, we argued against it but .NET Core will always support strong naming, there's no chance it will be dropped in future. We have to do our best to live with the future we have, not the one we hoped for.

The recent trend is to sign packages and publish the signing key, not signing packages will continually put us in a niche hold out, this sucks from a simplicity point of view as new Developers will need to "learn the ServiceStack way" and understand why we're maintaining separate Signed packages.

We're not concerned with the effort on our side to support it technically, we've already invested the necessary effort to support separate Signed packages. Our preference is for Simplicity and which scenario will offer higher utility and require less cognitive overhead. Our major versions with structural changes like this are very few and far between so we'd like to make sure we do what's best for our existing user base overall as we wont have any other chance to do this in the foreseeable future.

Member

mythz commented Jun 22, 2017

@Siliconrob The decision of whether .NET Core should drop Strong named support is long over, .NET Core and .NET will be supporting Strong naming forever.

You would keep the assembly fixed at 5 for all libraries seems like you forcing everyone to adopt the strong name peoples preferences and habits.

It's very common place to keep signed dlls at a constant major Assembly Version which we've been doing since 2013 with ServiceStack.Interfaces (and all our .Signed packages).

I understand this helps you with distribution channels and consolidating releases

We've already got the infrastructure in place to support creating .Signed packages, it's about simplicity, maximum utility of a single set of packages which will reduce docs and make life easier for developers who need to use strong named packages for whatever reason which looks like is over 20% of downloads. They currently have a sub-par experience who have to put in additional effort to get ServiceStack features work for their projects.

but I think it is going the wrong way, dropping strong name support is what I think is best overall for .NET Core going forward. I mean the older .NET is lost on this because of legacy applications, but here you have a chance to make a clean break on strong naming.

ServiceStack not signing packages has no influence on whether .NET Core will drop strong named support - that's over, we argued against it but .NET Core will always support strong naming, there's no chance it will be dropped in future. We have to do our best to live with the future we have, not the one we hoped for.

The recent trend is to sign packages and publish the signing key, not signing packages will continually put us in a niche hold out, this sucks from a simplicity point of view as new Developers will need to "learn the ServiceStack way" and understand why we're maintaining separate Signed packages.

We're not concerned with the effort on our side to support it technically, we've already invested the necessary effort to support separate Signed packages. Our preference is for Simplicity and which scenario will offer higher utility and require less cognitive overhead. Our major versions with structural changes like this are very few and far between so we'd like to make sure we do what's best for our existing user base overall as we wont have any other chance to do this in the foreseeable future.

@Siliconrob

This comment has been minimized.

Show comment
Hide comment
@Siliconrob

Siliconrob Jun 22, 2017

This explanation makes me understand your situation better. Thanks

Siliconrob commented Jun 22, 2017

This explanation makes me understand your situation better. Thanks

@maggarwal

This comment has been minimized.

Show comment
Hide comment
@maggarwal

maggarwal Jun 22, 2017

It'll be helpful to have all the packages signed. Currently sometimes there is a confusion when adding packages to new projects, specially for new people who don't understand the difference. It puts extra overhead to make sure whenever someone references the packages to new projects they are .Signed version and not the regular.

Thanks for all the awesome work.

maggarwal commented Jun 22, 2017

It'll be helpful to have all the packages signed. Currently sometimes there is a confusion when adding packages to new projects, specially for new people who don't understand the difference. It puts extra overhead to make sure whenever someone references the packages to new projects they are .Signed version and not the regular.

Thanks for all the awesome work.

@JBTuu5

This comment has been minimized.

Show comment
Hide comment
@JBTuu5

JBTuu5 Jul 1, 2017

Keep signed.

Have you considered obtaining a code signing cert to apply additional signing?

JBTuu5 commented Jul 1, 2017

Keep signed.

Have you considered obtaining a code signing cert to apply additional signing?

@mythz

This comment has been minimized.

Show comment
Hide comment
@mythz

mythz Jul 1, 2017

Member

Keep signed.

Note this issue is to track whether we should start signing the currently unsigned main ServiceStack packages.

Have you considered obtaining a code signing cert to apply additional signing?

No if we sign we'll be publishing our signing key so anyone can continue to create their own custom builds of ServiceStack. Note we'd only be using strong naming for identity not security. i.e. to allow Customers who need strong naming to be able to use our primary NuGet packages instead of our .Signed ones.

Member

mythz commented Jul 1, 2017

Keep signed.

Note this issue is to track whether we should start signing the currently unsigned main ServiceStack packages.

Have you considered obtaining a code signing cert to apply additional signing?

No if we sign we'll be publishing our signing key so anyone can continue to create their own custom builds of ServiceStack. Note we'd only be using strong naming for identity not security. i.e. to allow Customers who need strong naming to be able to use our primary NuGet packages instead of our .Signed ones.

@mythz mythz closed this Oct 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment