Strong name signing the packages

[dyllew3]

Is the feature request related to a problem? Please elaborate.
Hi there, me and my team are trying to use blazor for projects in our company and are looking to test the rendering of components and we would like to use bunit. However any packages we use in our projects must be strong name signed, so I was wondering if it would be possible to get bunit packages strong name signed.

The suggested solution
Strong name signing the packages using an snk file. Have done so here https://github.com/dyllew3/bUnit/tree/feature/strong-name-signing

Describe any alternative solutions

Additional context

[egil]

Hi @dyllew3, thanks for the suggestion. I am not opposed to it, but I need to investigate and understand all the implications of signing bUnit.

[egil]

Getting bit wiser. One implication is that bUnit can only use other strongly named libraries (https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming) which might be challenging to get around.

[StefH]

Or you can just create 2 versions : one normal and one signed. In that case the consumer can decide.

[duracellko]

Getting bit wiser. One implication is that bUnit can only use other strongly named libraries (https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming) which might be challenging to get around.

Hmm.. are there any dependencies currently, which do not have strong name? Is there any risk there may be needed new dependency without strong name in future?

[duracellko]

@dyllew3 I would challenge the requirement that project can have only strongly named dependencies. I can imagine it is useful in certain scenarios:

• The project targets .NET Framework and some dependencies would be installed in GAC. Blazor does not target .NET Framework, however.
• Your team will create custom shared framework (.NET Core alternative of GAC) and distribute dependencies in the shared framework.
• Your product is redistributable library and consumers may use one of scenarios above.

Otherwise strong name does not have much value. Keep in mind that strong name is not security mechanism. Especially with the recommendation in mentioned strong name guidance to store strong name key in source code repository for open source projects.

If you are looking for security mechanism then required technology is NuGet package signing and DLL signing using AuthentiCode. However, I think there is not many NuGet packages providing this.

[egil]

Getting bit wiser. One implication is that bUnit can only use other strongly named libraries (https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming) which might be challenging to get around.

Hmm.. are there any dependencies currently, which do not have strong name? Is there any risk there may be needed new dependency without strong name in future?

I have not verified it yet, but bUnit would not be the same without AngleSharp.

As for whether there is value of doing this, I can understand that corporate policies can be impossible to reason with, so I want to support this if it is reasonably possible.

[dyllew3]

I believe you should be able to use non strongly named libraries it will just throw warnings on build

[AndreyTretyak]

It looks like the only unsigned package that you depend on is AngleSharp.Diffing, so ideally it should be signed too. Signed DLL that depends on unsigned won't be usable in the signed project.

Also, I don't think it makes sense to publish two versions (signed and unsigned), since the signed version could be used by both signed and unsigned projects.

So you are right that enabling a strong name sign would limit you to depending only on strong-named DLLs (thankfully most of them are), but in return, your library could be used by more people.

In our case, it's forbidden to run unsigned DLLs on the machines. It helps to ensure the identity of the producer for proprietary DLLs and to do that they should depend only on signed DLLs. If I'm not mistaken it's also helpful for the cases when you need to load two versions of the same DLL, although I'm not sure if it's applicable here.

[duracellko]

In our case, it's forbidden to run unsigned DLLs on the machines. It helps to ensure the identity of the producer for proprietary DLLs and to do that they should depend only on signed DLLs. If I'm not mistaken it's also helpful for the cases when you need to load two versions of the same DLL, although I'm not sure if it's applicable here.

Be aware that strong name signing has not much to do with security. It does not identify publisher at all. Especially for open source projects, where it fine to make signing key public (not secret) and thus anyone can produce DLL with the same strong name. The idea is that it's easier to fork open source projects.

The technology you are looking for is AuthentiCode or binary signing. https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode (this is for drivers, but it works for any executable code). That is exactly the technology to identify publisher.

[egil]

It looks like the only unsigned package that you depend on is AngleSharp.Diffing, so ideally it should be signed too. Signed DLL that depends on unsigned won't be usable in the signed project.

Unsigned or strongly named? Is that the same thing?

EIther way, I am creator/maintainer for AngleSharp.Diffing, so I am in a good position to get that signed as well.

Also, I don't think it makes sense to publish two versions (signed and unsigned), since the signed version could be used by both signed and unsigned projects.

Agreed, that also goes against the recommendations from Microsoft.

[chrissainty]

Hey @egil, I've had requests for Blazored.LocalStorage to be signed as well as a couple of the other libraries. We're now adding a dependancy on bUnit as we move to improve testing and providing testing helpers. So there is little point in us signing Blazored if bUnit isn't signed.

Be great to know what you're thinking about this.

[egil]

Hey @chrissainty, bUnit depends on AngleSharp, which I just noticed is strongly named, so I guess that removed the roadblock I have.

However, I wonder why this is an issue for you. Your library (Blazored.LocalStorage) can be strongly signed and still be testable from a test project that is not (Blazored.LocalStorage.Tests), can it not?

Anyway, I do not mind strongly signing the library, so ill see about moving this up the priority list.