Recommendations for subscribing .NET assemblies?

I have a solution consisting of five projects, each of which is compiled to separate assemblies. I'm signing the code right now, but I'm sure I'm doing it wrong. What is the best practice here?

  • Sign each other key; make sure the passwords are different from each other.
  • Sign each other key; use the same password if you want
  • Sign each with the same key
  • Something else completely

Basically, I'm not quite sure what โ€œsigningโ€ does with them, or what are the best practices here, so a more general discussion will be good. All I really know is that FxCop yelled at me, and it was easy to fix by clicking the Sign this assembly and .pfx checkbox using Visual Studio (2008).

+44
assemblies signing
Aug 29 '08 at 21:48
source share
5 answers

If your only goal is to stop FxCop from screaming at you, then you have found the best practice.

The best practice for signing your assemblies is that it completely depends on your goals and needs. We will need additional information, for example, the planned deployment:

  • For personal use.
  • For use on a corporate PC network as a client application
  • Work on a web server
  • Running in SQL Server
  • Uploaded over the Internet
  • Sold on CD in shrink film
  • Loaded directly into the cybernetic brain.
  • Etc.

Typically, you use code signing to ensure that assemblies are sourced from a specific trusted source and have not been modified. Thus, each with the same key is excellent. Now, as this trust and identification is defined, this is another story.

UPDATE:. How beneficial is it to your end users when deploying over the Internet if you have received a certificate of certification from a certification authority . Then, when they download your assemblies, they can confirm that they came from Domenic Software Emporium and that they were not modified or damaged along the way. You will also want to sign the installer when it is downloaded. This prevents the warning that some browsers show that it was obtained from an unknown source.

Note. You will pay for a software signature certificate. What you get is a certification authority that has become a trusted third party that checks who you are. This works because of a trust network that accesses the root certificate installed on their operating system. There are several certification authorities to choose from, but you must make sure that they are supported by root certificates in the target operating system.

+41
Aug 29 '08 at 21:56
source share
โ€” -

The most obvious difference between signed and unsigned assemblers is the ClickOnce application. If you do not sign it, then when you first start the application, users will receive a terrible warning dialog "Unknown publisher." If you signed it with a certificate of a trusted authority , then they see a dialog box that is less scary. As far as I know, signing with a certificate that you create yourself does not affect the Unknown Publisher warning. Comodo Instant SSL provides sample dialogs.

There are several more subtle differences. You must sign the assembly before it can be installed in the global assembly cache (GAC), where it can be used by several applications. Signing is an integral part of code access security (CAS), but I have not found anyone who could get CAS to work. I am sure that both the GAC and CAS work great with certificates that you create yourself.

+7
Sep 05 '08 at 20:26
source share

This helps because the executable is expecting a strongly named assembly. This stops anyone maliciously replacing in another assembly for one of yours. The user can also provide CAS permissions for assembly based on a strong name.

I donโ€™t think you should distribute the .pfx file, you keep it safe to refuse the build.

+3
Aug 29 '08 at 22:11
source share

Signing is used to uniquely identify the assembly. See How to Build (Visual Studio) for more information .

From a best practice point of view, it is enough to use the same key if the assemblies have different names.

+2
Aug 29 '08 at 22:00
source share

It is important to keep the PFX secret file as it contains the private key.

If this key becomes available to others, everyone can sign assemblies or programs that disguise themselves as you.

To associate your name with your builds (in the eyes of Windows), you will need to get a digital certificate (part of the PFX file containing your name), signed by a trusted authority.

In fact, you will receive a new certificate, but with the same information.

You will have to pay for this certificate (possibly annually), but the certification authority will vouch for your existence (after you send it faxes you a copy of your passport or driverโ€™s license and internal account).

+2
Sep 11 '08 at 9:23
source share



All Articles