Signed assemblies

[Intelligence4]

In some development scenarios, i.e. COM add-ins for Office, all assemblies must be signed. Up until now I have been able to sign your assembly myself. However, new changes to how nuget works and store packages does not allow that possibility anymore. Would it be possible to provide your ExtendedXmlSerializer as a signed assembly?

[issue-label-bot]

Issue Label Bot is not confident enough to auto-label this issue. See dashboard for more details.

[Mike-E-angelo]

Oh man, @Intelligence4 that's a good one. I recall v1 was signed, but when we looked into signing v2 assemblies (discussed in #52), it unveiled some complications. Primarily, it was discovered that signing assemblies was really no longer a recommendation for .NET packages.

However, that doesn't mean I am totally against it. I guess it boils down to how complicated it is and what is involved. I would assume it means creating a key and if that costs anything? I would need to investigate and collect some more information.

To start, if you can provide any resources on your side I can look into it further. Specifically, I am interested in NuGet's changes and any related resources/recommendations around them. A quick search didn't turn up anything obvious for me.

[Intelligence4]

Hi Mike-E The assumption that you have made about no longer signing assemblies is for the new net core world and not the old world. COM add-in development for office automatically generates assembly key files (i.e. signing) and requires a signed assembly for the “security” model that Office implements. I am really not sure that, beyond signing the assembly, anything more has to be done on your side. From the “old” dotnet world: https://docs.microsoft.com/en-us/dotnet/standard/assembly/strong-named?redirectedfrom=MSDN Do not rely on strong names for security. They provide a unique identity only. Of course, there is the “issue” of providing the key file in the repository. But is this really an issue given the above (old world) statement from Microsoft? Unfortunately, I have not really found a great deal of information: https://www.codeproject.com/articles/8874/strong-names-explained https://docs.microsoft.com/en-us/dotnet/standard/assembly/sign-strong-name?redirectedfrom=MSDN Nuget moved away from the packages file to the .nuget file repository under the windows user directory for Visual Studio. This means that your package no longer appears in the packages directory of the solution, but in the user’s .net file repository. This makes the strong name with post compilation utilities almost impossible in certain ALM/CI situations (this is the problem we are currently encountering). To test the working of the new nuget package storage nothing more than a signed console app referencing your nuget package is required. I would appreciate is you could give me an indication of how you wish to proceed with this matter as I will have to either recode with another XML library, push the user story to low priority or remove the it from the backlog. Obviously signing the ExtendedXmlSerializer would cause us the least amount of work. Regards Von: Mike-E <notifications@github.com> Gesendet: Freitag, 14. August 2020 12:00 An: ExtendedXmlSerializer/home <home@noreply.github.com> Cc: Graham McDonald <graham.mcdonald@smartoutcome.ch>; Mention <mention@noreply.github.com> Betreff: Re: [ExtendedXmlSerializer/home] Signed assemblies (#425) Oh man, @Intelligence4<https://github.com/Intelligence4> that's a good one. I recall v1 was signed, but when we looked into signing v2 assemblies (discussed in #52<#52>), it unveiled some complications. Primarily, it was discovered that signing assemblies was really no longer a recommendation for .NET packages<https://github.com/dotnet/corefx/blob/c02d33b18398199f6acc17d375dab154e9a1df66/Documentation/project-docs/strong-name-signing.md#faq>. However, that doesn't mean I am totally against it. I guess it boils down to how complicated it is and what is involved. I would assume it means creating a key and if that costs anything? I would need to investigate and collect some more information. To start, if you can provide any resources on your side I can look into it further. Specifically, I am interested in NuGet's changes and any related resources/recommendations around them. A quick search didn't turn up anything obvious for me. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#425 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOVZSHG5YDGN2IKLJWOWQTTSAUDKBANCNFSM4P7KLECQ>.

[Mike-E-angelo]

Obviously signing the ExtendedXmlSerializer would cause us the least amount of work.

Yeah I hear you @Intelligence4 this would be nice to have. The trick though is that the least amount of work for you means a good amount of work for me. 😁

I took a preliminary look into it. There are several issues with some notes:

• I would have to find out how to create another nupkg: ExtendedXmlSerializer.Signed. The trick here is leveraging the existing ExtendedXmlSerializer.csproj file and basically copy its contents (using all its classes/configuration) while kicking out another nupkg that only contains .NET Framework versions and is then subsequently signed.
• Create new NuGet entry. I am not entirely familiar with this as I did not make the original one. Might not be too big of a deal, however.
• Updating AppVeyor CI script to post the new package to the proper place. Maybe this is not a big deal either as right now it is configured for *.nupkg so as long as the package is registered on NuGet it should post.

Do you by chance happen to have another repository/project that has this working as you expect it? The challenge here is that it would need to be a repository/project that works nicely with both .NET Core and .NET Framework, and kicking out a signed nupkg that is for the .NET Framework versions only.

If you have something that I can reference, and it's basically something that can be copy/pasted/configured, this could be doable. Otherwise, as per #383 my time/focus is really only limited here for bug fixes and maintenance for the foreseeable future.

[Mike-E-angelo]

OK @Intelligence4 I poked around this some more and figured something out. Not sure if it will work, but might be promising.

Looks like AppVeyor detects the nupkg just fine and adds it to the artifacts. Please check out the nupkg that contains the signed assembly here:

https://ci.appveyor.com/project/ExtendedXmlSerializer/extendedxmlserializer/builds/34662089/artifacts

Note that during the build process, I get several warnings:

1>CSC : warning CS8002: Referenced assembly 'LightInject, Version=6.2.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.
1>CSC : warning CS8002: Referenced assembly 'Sprache, Version=2.2.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

So, not sure if this will be an issue, but it's a starting point.

AppVeyor

[Intelligence4]

Hi Sorry about taking so long to get back in touch. I am not sure that producing a signed version is going to be that easy given that you seem to having the same type of problems we are currently having. I think that it would be better for you to shelf this development at the moment as I am not sure as to our decision regarding the options mentioned earlier. BTW when one assembly in the chain remains unsigned then the MS-Office “security” model will not load the offending assembly/sub assembly. Simple put, all of your linked assemblies must also be signed including the 3rd party ones. Unfortunately, this puts you in the same position that we are in. If we decide that we want a signed ExtendedXmlSerializer that can be built in our CI/ALM process, it might be better that we fork your development and assess/implement the required changes. Thanks so far for your help. Von: Mike-E <notifications@github.com> Gesendet: Freitag, 14. August 2020 17:26 An: ExtendedXmlSerializer/home <home@noreply.github.com> Cc: Graham McDonald <graham.mcdonald@smartoutcome.ch>; Mention <mention@noreply.github.com> Betreff: Re: [ExtendedXmlSerializer/home] Signed assemblies (#425) OK @Intelligence4<https://github.com/Intelligence4> I poked around this some more and figured something out. Not sure if it will work, but might be promising. Looks like AppVeyor detects the nupkg just fine and adds it to the artifacts. Please check out the nupkg that contains the signed assembly here: https://ci.appveyor.com/project/ExtendedXmlSerializer/extendedxmlserializer/builds/34662089/artifacts Note that during the build process, I get several warnings: 1>CSC : warning CS8002: Referenced assembly 'LightInject, Version=6.2.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name. 1>CSC : warning CS8002: Referenced assembly 'Sprache, Version=2.2.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name. So, not sure if this will be an issue, but it's a starting point. </assets/images/favicon-blue.ico>[X]</assets/images/favicon-blue.ico></assets/images/favicon-blue.ico> AppVeyor<https://ci.appveyor.com/project/ExtendedXmlSerializer/extendedxmlserializer/builds/34662089/artifacts> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#425 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOVZSHGAEHMBN2EKFOYOHUTSAVJRFANCNFSM4P7KLECQ>.

[Mike-E-angelo]

BTW when one assembly in the chain remains unsigned then the MS-Office “security” model will not load the offending assembly/sub assembly. Simple put, all of your linked assemblies must also be signed including the 3rd party ones. Unfortunately, this puts you in the same position that we are in.

That was my concern and understanding, hoping to be proven wrong. Well, we gave it a shot and got as far as we could. This may also prove valuable for someone else who wants to have a signed version, too. Well, at least they will get to the bad news quicker. 😭

Alright, thanks for bringing this up and too bad we couldn't get it to happen. Please do let me know of any other questions/concerns/issues you do find and I will do my best to help you out. Closing for now.