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

[Blocker] Microsoft.Toolkit.Windows.UI.Controls.dll is not signed #2198

Closed
purani opened this Issue Jun 4, 2018 · 25 comments

Comments

Projects
None yet
7 participants
@purani

purani commented Jun 4, 2018

Microsoft.Toolkit.Windows.UI.Controls.dll is not signed

Regression: No
Bug report (I searched for similar issues and did not find one)

The dll has publickey as null and it is not signed. So it is not usable in our projects which use and generate signed assemblies

Runtime error:
Could not load file or assembly 'Microsoft.Toolkit.Win32.UI.Controls, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)

Expecting a signed dll asap to unblock our work

Environment

Nuget Package(s): issue is seen in both internal and external feeds

Package Version(s): 3.1.0.0

Windows 10 Build Number:
- [ ] Creators Update (15063)
- [ ] Fall Creators Update (16299)
- [x] April 2018 Update (17134)
- [ ] Insider Build (build number: )

App min and target version:
- [ ] Creators Update (15063)
- [ ] Fall Creators Update (16299)
- [x] April 2018 Update (17134)
- [ ] Insider Build (xxxxx)

Device form factor:
- [ ] Desktop
- [ ] Mobile
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Visual Studio 
- [ ] 2017 (version: )
- [ ] 2017 Preview (version: )

@nmetulev

This comment has been minimized.

Show comment
Hide comment
@nmetulev

nmetulev Jun 4, 2018

Member

The latest version the package is 3.0.0 (not 3.1.0) and is already signed: https://www.nuget.org/packages/Microsoft.Toolkit.Win32.UI.Controls. Where are you getting 3.1 from?

Member

nmetulev commented Jun 4, 2018

The latest version the package is 3.0.0 (not 3.1.0) and is already signed: https://www.nuget.org/packages/Microsoft.Toolkit.Win32.UI.Controls. Where are you getting 3.1 from?

@rjmurillo

This comment has been minimized.

Show comment
Hide comment
@rjmurillo

rjmurillo Jun 4, 2018

Member

Are the DLLs in the package strong named? I didn't think they were

Member

rjmurillo commented Jun 4, 2018

Are the DLLs in the package strong named? I didn't think they were

@nmetulev

This comment has been minimized.

Show comment
Hide comment
@nmetulev

nmetulev Jun 4, 2018

Member

Agh, they are not. The nugets are signed, is there a reason to strong name the DLLs as well? Not sure of the pro vs cons of strong naming.

Member

nmetulev commented Jun 4, 2018

Agh, they are not. The nugets are signed, is there a reason to strong name the DLLs as well? Not sure of the pro vs cons of strong naming.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jun 4, 2018

Collaborator

unfortunately, it's a lost battle. There's no reason other than if someone else needs to be strong named, they break if they reference you.

The recommended solution is to check the snk into the repo and be done with it. That said, it's technically a breaking change since it alters the assembly identity.

Collaborator

onovotny commented Jun 4, 2018

unfortunately, it's a lost battle. There's no reason other than if someone else needs to be strong named, they break if they reference you.

The recommended solution is to check the snk into the repo and be done with it. That said, it's technically a breaking change since it alters the assembly identity.

@rjmurillo

This comment has been minimized.

Show comment
Hide comment
@rjmurillo

rjmurillo Jun 4, 2018

Member

Pros

  • Allows assemblies to live in GAC. Strong naming guarantees a unique name, guarantees version lineage, etc.
  • Unsigned assemblies can be used exclusively by unsigned assemblies, whereas signed assemblies can be used by both signed and unsigned assemblies.

Cons

  • You can't reference an unsinged assembly from a signed assembly. All assemblies we use, including any third party stuff, would also need to be signed.
  • The signing is a bit of a pain. We would now have delay signed assemblies (since we don't want just anyone to produce an assembly with our identity), and the build server the only one able to sign the assemblies.

Typically folks want strong named assemblies because of some distribution reason: they want to share something between multiple applications and GAC install, or their distribution system requires strong naming (e.g. ClickOnce).

Member

rjmurillo commented Jun 4, 2018

Pros

  • Allows assemblies to live in GAC. Strong naming guarantees a unique name, guarantees version lineage, etc.
  • Unsigned assemblies can be used exclusively by unsigned assemblies, whereas signed assemblies can be used by both signed and unsigned assemblies.

Cons

  • You can't reference an unsinged assembly from a signed assembly. All assemblies we use, including any third party stuff, would also need to be signed.
  • The signing is a bit of a pain. We would now have delay signed assemblies (since we don't want just anyone to produce an assembly with our identity), and the build server the only one able to sign the assemblies.

Typically folks want strong named assemblies because of some distribution reason: they want to share something between multiple applications and GAC install, or their distribution system requires strong naming (e.g. ClickOnce).

@rjmurillo

This comment has been minimized.

Show comment
Hide comment
@rjmurillo

rjmurillo Jun 4, 2018

Member

Interesting aside: you can see the conversation for XamlBehaviors here: Microsoft/XamlBehaviors#29

Member

rjmurillo commented Jun 4, 2018

Interesting aside: you can see the conversation for XamlBehaviors here: Microsoft/XamlBehaviors#29

@rjmurillo

This comment has been minimized.

Show comment
Hide comment
@rjmurillo

rjmurillo Jun 4, 2018

Member

For the most part, I don't think it makes sense for the toolkit to strong name for two reason:

  1. Toolkit contains mostly UWP items, which do not have the concept of assembly redirection and no need for strong naming.
  2. Only case we would need strong naming is for a classic Winforms/WPF application referencing items in the toolkit that itself is strong-named.

We could do as @onovotny says and just check in the key so that whomever needs it can strong sign. We can protected the binaries to distinguish between those that strong name and our strong named (if we decide) by signing the binaries like we do the packages.

All I know that working with delay signed assemblies is a pain, slows everything down, and I'd rather not deal with it.

Member

rjmurillo commented Jun 4, 2018

For the most part, I don't think it makes sense for the toolkit to strong name for two reason:

  1. Toolkit contains mostly UWP items, which do not have the concept of assembly redirection and no need for strong naming.
  2. Only case we would need strong naming is for a classic Winforms/WPF application referencing items in the toolkit that itself is strong-named.

We could do as @onovotny says and just check in the key so that whomever needs it can strong sign. We can protected the binaries to distinguish between those that strong name and our strong named (if we decide) by signing the binaries like we do the packages.

All I know that working with delay signed assemblies is a pain, slows everything down, and I'd rather not deal with it.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jun 4, 2018

Collaborator

@rjmurillo there's no need to delay sign if the key is checked in. That's the recommended practice from the .NET team and I'd like to ensure that's the case -- since it enables forks/local builds, etc. Strong naming doesn't provide any security, it's just for identity purposes. We'll still authenticode sign all the binaries and nuget package, and that's how people know they have an official build.

We'd need to sign any of the common .NET Standard libraries too since they could be used by the desktop framework as well.

My main reason to sign is that it only hurts our users if we don't. Breaking change aside, there's nothing to lose by doing it, other than swallowing the sour milk once.

Collaborator

onovotny commented Jun 4, 2018

@rjmurillo there's no need to delay sign if the key is checked in. That's the recommended practice from the .NET team and I'd like to ensure that's the case -- since it enables forks/local builds, etc. Strong naming doesn't provide any security, it's just for identity purposes. We'll still authenticode sign all the binaries and nuget package, and that's how people know they have an official build.

We'd need to sign any of the common .NET Standard libraries too since they could be used by the desktop framework as well.

My main reason to sign is that it only hurts our users if we don't. Breaking change aside, there's nothing to lose by doing it, other than swallowing the sour milk once.

@onovotny onovotny referenced this issue Jun 4, 2018

Merged

Add assembly strong naming #2200

0 of 7 tasks complete
@michael-hawker

This comment has been minimized.

Show comment
Hide comment
@michael-hawker

michael-hawker Jun 5, 2018

Contributor

Does that mean we should do this for 4.0?

Contributor

michael-hawker commented Jun 5, 2018

Does that mean we should do this for 4.0?

@rjmurillo

This comment has been minimized.

Show comment
Hide comment
@rjmurillo

rjmurillo Jun 5, 2018

Member

I like the idea of doing in the next major officially, since it is a breaking change, but keeping the key checked in for this person so they can strong sign their own version until then.

Member

rjmurillo commented Jun 5, 2018

I like the idea of doing in the next major officially, since it is a breaking change, but keeping the key checked in for this person so they can strong sign their own version until then.

@purani

This comment has been minimized.

Show comment
Hide comment
@purani

purani Jun 6, 2018

Thanks for taking this up. Can you please check-in the key and let me know the internal build number in which it is available.

purani commented Jun 6, 2018

Thanks for taking this up. Can you please check-in the key and let me know the internal build number in which it is available.

@skendrot

This comment has been minimized.

Show comment
Hide comment
@skendrot

skendrot Jun 6, 2018

Collaborator

Devil's advocate: Why sign them at all? This is an open source project. Users can download the source and sign the assemblies themselves. We don't have plans to install these in the GAC so that isn't a concern.

Collaborator

skendrot commented Jun 6, 2018

Devil's advocate: Why sign them at all? This is an open source project. Users can download the source and sign the assemblies themselves. We don't have plans to install these in the GAC so that isn't a concern.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jun 6, 2018

Collaborator

@skendrot

A couple reasons:

  1. It makes it harder for our users
  2. If there are libraries that build on the toolkit and take the toolkit as a dependency, you'd still run into issues that are painful to workaround.
Collaborator

onovotny commented Jun 6, 2018

@skendrot

A couple reasons:

  1. It makes it harder for our users
  2. If there are libraries that build on the toolkit and take the toolkit as a dependency, you'd still run into issues that are painful to workaround.

@nmetulev nmetulev added this to the 4.0 milestone Jul 11, 2018

@PedroLamas

This comment has been minimized.

Show comment
Hide comment
@PedroLamas

PedroLamas Jul 12, 2018

Collaborator

I see no practical reason at all to strong sign an assembly.

If we strong-sign this project, any third party NuGet package that didn't specify a dependent version will be automatically broken (package A depending on the toolkit, but didn't specify a particular version).

Also, if a project has a dependency on packages A and B and they depend on different strong-signed versions of the toolkit, that becomes a problem!

Please correct me if I'm wrong here, because from where I stand if we do this, we are going down DLL hell!!

Collaborator

PedroLamas commented Jul 12, 2018

I see no practical reason at all to strong sign an assembly.

If we strong-sign this project, any third party NuGet package that didn't specify a dependent version will be automatically broken (package A depending on the toolkit, but didn't specify a particular version).

Also, if a project has a dependency on packages A and B and they depend on different strong-signed versions of the toolkit, that becomes a problem!

Please correct me if I'm wrong here, because from where I stand if we do this, we are going down DLL hell!!

@PedroLamas

This comment has been minimized.

Show comment
Hide comment
@PedroLamas

PedroLamas Jul 12, 2018

Collaborator

Interesting aside: you can see the conversation for XamlBehaviors here: Microsoft/XamlBehaviors#29

I still remember that discussion and I find it amazing we keep going back to the same subject, so I ask: has anything changed since that "old" topic?

Collaborator

PedroLamas commented Jul 12, 2018

Interesting aside: you can see the conversation for XamlBehaviors here: Microsoft/XamlBehaviors#29

I still remember that discussion and I find it amazing we keep going back to the same subject, so I ask: has anything changed since that "old" topic?

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jul 12, 2018

Collaborator

This is beaten to death. It is required if other consumers of our library must be strong named. We know of several of them that need to be strong named and thus we have to be. The solution is to take the breaking change as an error (we should have done it before), and move on. There's no good answer here.

Collaborator

onovotny commented Jul 12, 2018

This is beaten to death. It is required if other consumers of our library must be strong named. We know of several of them that need to be strong named and thus we have to be. The solution is to take the breaking change as an error (we should have done it before), and move on. There's no good answer here.

@PedroLamas

This comment has been minimized.

Show comment
Hide comment
@PedroLamas

PedroLamas Jul 12, 2018

Collaborator

So why don't they just use StrongNamer or something similar in their projects?

My point is that there is a solution for those who require this project to be strong-named, but AFAIK there won't be any solution for those who have mixed version dependencies...

Collaborator

PedroLamas commented Jul 12, 2018

So why don't they just use StrongNamer or something similar in their projects?

My point is that there is a solution for those who require this project to be strong-named, but AFAIK there won't be any solution for those who have mixed version dependencies...

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jul 12, 2018

Collaborator

StrongNamer is a very bad hack and cannot be used for other shared components. Again, I can't say which one, but there are other products that want to use the modern WebView, that themselves have other people referencing them. We have to do it the right way. StrongNamer is not professional or valid here.

That's why it's a major version bump, it's a breaking change.

Collaborator

onovotny commented Jul 12, 2018

StrongNamer is a very bad hack and cannot be used for other shared components. Again, I can't say which one, but there are other products that want to use the modern WebView, that themselves have other people referencing them. We have to do it the right way. StrongNamer is not professional or valid here.

That's why it's a major version bump, it's a breaking change.

@PedroLamas

This comment has been minimized.

Show comment
Hide comment
@PedroLamas

PedroLamas Jul 12, 2018

Collaborator

I can understand that, however, you didn't tell me how are we going to fix the scenario where dependencies A and B require different versions of the toolkit!
Is there any assembly redirection in UWP (manual or otherwise) that I'm not aware of?

Collaborator

PedroLamas commented Jul 12, 2018

I can understand that, however, you didn't tell me how are we going to fix the scenario where dependencies A and B require different versions of the toolkit!
Is there any assembly redirection in UWP (manual or otherwise) that I'm not aware of?

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jul 12, 2018

Collaborator

if A and B require different versions of the toolkit, then there will be problems. But that'd be true strong name or otherwise if there's a breaking change.

Suppose a type was removed from v4 and that A, which needed it and used v3 was fine. Now B needs v4.... you have the same issue. You can't use A and B in that case easily today.

Collaborator

onovotny commented Jul 12, 2018

if A and B require different versions of the toolkit, then there will be problems. But that'd be true strong name or otherwise if there's a breaking change.

Suppose a type was removed from v4 and that A, which needed it and used v3 was fine. Now B needs v4.... you have the same issue. You can't use A and B in that case easily today.

@PedroLamas

This comment has been minimized.

Show comment
Hide comment
@PedroLamas

PedroLamas Jul 12, 2018

Collaborator

That's a very fair point there indeed: one does have issues on major versions dependencies, but I guess that's why we make breaking changes only when we change major version (v3 to v4 in your example).

However, strong-signing will cause minor versions issues, so a project with dependencies requiring different toolkit versions will be broken (v4.0.0 to v4.0.1).

Collaborator

PedroLamas commented Jul 12, 2018

That's a very fair point there indeed: one does have issues on major versions dependencies, but I guess that's why we make breaking changes only when we change major version (v3 to v4 in your example).

However, strong-signing will cause minor versions issues, so a project with dependencies requiring different toolkit versions will be broken (v4.0.0 to v4.0.1).

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jul 12, 2018

Collaborator

v4 to v4.0.1 will require binding redirects if we change the assembly version. We can decide what we want to do there.

That said, AutoGenerateBindingRedirects does this for you automatically these days

Collaborator

onovotny commented Jul 12, 2018

v4 to v4.0.1 will require binding redirects if we change the assembly version. We can decide what we want to do there.

That said, AutoGenerateBindingRedirects does this for you automatically these days

@PedroLamas

This comment has been minimized.

Show comment
Hide comment
@PedroLamas

PedroLamas Jul 12, 2018

Collaborator

That said, AutoGenerateBindingRedirects does this for you automatically these days

If that works properly for UWP, I'll shut up now and give it a rest! 😄

Collaborator

PedroLamas commented Jul 12, 2018

That said, AutoGenerateBindingRedirects does this for you automatically these days

If that works properly for UWP, I'll shut up now and give it a rest! 😄

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jul 12, 2018

Collaborator

UWP doesn't need binding redirects because it ignores strong names :) Neither does Xamarin or .NET Core.

This only affects usage on the .NET Framework.

Collaborator

onovotny commented Jul 12, 2018

UWP doesn't need binding redirects because it ignores strong names :) Neither does Xamarin or .NET Core.

This only affects usage on the .NET Framework.

@PedroLamas

This comment has been minimized.

Show comment
Hide comment
@PedroLamas

PedroLamas Jul 12, 2018

Collaborator

Well, that works for me!! 😁

Collaborator

PedroLamas commented Jul 12, 2018

Well, that works for me!! 😁

@nmetulev nmetulev closed this in #2200 Jul 16, 2018

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