My trusted secret inner circle.

Before I jump right in, I want to give some major credit to the author of the MSDN articles that cover this same information.  The information on this Blog is not meant to replace any of the information that is covered in the MSDN, but rather as a supplement and personal look based upon my own observations.  I have a lot of respect for the content on MSDN as it is the best reference for how this stuff works.  So, "props" to the writers of the MSDN articles on VSTO deployment, I really do feel they are top class in quality and it shows.

On to content!

I have a secret list.  In my list, I have a set of names of those that I trust so much, I will entrust the health of my computer to them.  Yes, I have a list where I include those names within my secret inner circle of "Full Trust".

This post is about the VSTO inclusion list.  In this post I'm going to try an point out all of the advantages, disadvantages and weird little hang-ups that can come from using the inclusion list.

Briefly I'd like to point out that the trust-prompt and the inclusion list both are different heads of the same beast.  When the user clicks the install button, VSTO creates an appropriate inclusion list entry based on the information about the solution it is prompting about. 

The inclusion list is fairly simple in what it does.  Basically you can do 3 operations to the inclusion list using the inclusion list api.  You can add an entry, remove an entry or check if an entry exists in the list.  You can find a detailed article on the API here: https://msdn2.microsoft.com/en-us/library/bb398239.aspx

The entries in the list consist of 2 parts, a “fully qualified” location (full path) to a deployment manifest (.vsto file) and a string value that contains the XML public key value of the certificate used to sign the manifests.  We require both values for an entry because we want to ensure the trust entry is not just for the location but also the correct contents of that location.  If the signing certificate were to change, a new entry must be created for it because it’s possible that the change wasn’t a valid change but an attempt to hijack the solution and replace it with something “bad”.

What may not be as clear though, are some of the factors that surround the inclusion list itself.  There are basically five ways in which the inclusion list may not be able to trust the solution and only one way in which it will.

If a solution (specifically the .vsto file) exists in a temporary folder it probably cannot be trusted.  There are a specific set of temporary folders which VSTO customization are not allowed to run from. I believe this is particularly noticeable with add-ins sent via e-mail.  In order to install an add-in that was sent to a user via an email, they would have to copy the files to a normal folder first.

If the ClickOnce prompting level for a zone of a solution is set to “AuthenticodeRequired”, the signing certificate must be known.  This means that a solution signed by a certificate that did not come from a trusted root authority (such as VeriSign) will not be trusted even if an inclusion list entry was created.  The trust prompt will not show in this case either.  This is of particular note because by default, on a regular windows XP machine install, the Internet zone is set to “AuthenticodeRequired”.  A simple user-level work-a-round for a solution they really do trust despite a questionable certificate is to add the deployment address to the Trusted Internet Sites List.  Generally, for professional solutions I recommend obtaining an appropriate certificate from a well known Certificate Authority.  Using the trusted sites work-a-round is not as in-appropriate for very small “hobbyist” type applications.

It is possible prompting for the zone of the solution to simply be disabled.  If this is the case, inclusion entries will not grant trust to VSTO solutions in that zone.  There’s a more detailed article about the different zones and how to set them here: https://msdn2.microsoft.com/en-us/library/bb772070.aspx. 

Generally I feel the developer should not be configuring the zone values though, this is more appropriate for the administrator of the user machine.

If the solution exists in the “Internet Untrusted Sites List” it is “UnTrusted” and it will not install.

A solution signed by an “UnTrusted” certificate will never install, inclusion entry existing or not.

Hopefully my explanation has been pretty clear.  I’d like to talk a little bit more about the “why” of the inclusion list now.  There are some distinct advantages to using the inclusion list.  The one that comes to mind specifically is that the degree of trust required prior to publishing is much smaller.  Any developer can obtain a certificate for code-signing via the various Certificate authorities.  Most major authorities will be trusted by default so at least for being “known” the process isn’t too hard.  To have your certificate specifically trusted takes a lot more infrastructure on the user’s machine though.  For most enterprises it’s possible to push down trust of a certificate through IT management tools.  To target the larger group such as random internet users however, getting a certificate to be trusted is a lot more work. 

The API itself is good for custom installers.  If for some reason a developer doesn’t want to use Click-Once, but rather some third party installer, the API provides a method for the developer to bypass the prompt.  This is particularly of note when a solution is installed using |vstolocal (I’ll cover this scenario in the future).  The prompt isn’t particularly destructive, but if the user goes out of their way to run a custom setup program we can assume they really do want to install the VSTO part. 

All that said, here’s some completely unrelated information:

I’m taking a short break for the holidays and as such will not be as readily available.  My plans for my vacation include spending some time with my parents in Idaho and spending some time playing games.  I may also try to catch up with some people while I’m in the area so it’s possible I may have some other interesting projects or observations to write about (I’ve been so focused on VSTO deployment the last couple of months, my brain feel like it’s on a pair of rails).  I plan to resume blogging next year.  I may delve more into some of the other interesting technical aspects of what I do to add some flavorful variety; we will just have to see.

Thank You for Reading.

Kris

Comments

• Anonymous
  October 17, 2010
  Hello Kristopher does this inclusion list registry entry work also for Office 2003 version ??

• Anonymous
  October 20, 2010
  It will not work work with 2003, the inclusion list only applies to Office 2007 and Office 2010 (using VS 2008 and later).

• Anonymous
  October 20, 2010
  Hello Kristopher thanks for the reply.. could you please guide me on how to apply security policies in case of Office 2003 apps... is it thru the SetSecurity class, i.e. using the caspol command  ? or is there any other way... Thanks in advance

• Anonymous
  October 21, 2010
  My familiarity with the caspol model used in VSTO 2003 and 2005SE are not that great.  However, there's a great whitepaper that talks about everything you need to know here: go.microsoft.com/fwlink

• Anonymous
  October 21, 2010
  Hello Kristopher Thank you again for the response, i did go thru both the pages regarding the deployment, and with some other pages' help - blogs.msdn.com/.../8994631.aspx msdn.microsoft.com/.../bb332051.aspx msdn.microsoft.com/.../aa537173%28office.11%29.aspx social.msdn.microsoft.com/.../38bb966b-fb1e-48e9-b120-0f73dd661109 ,was able to apply the caspol security method perfectly... :)  ...(just a few links for anybody else who tries this method) thanks again excellent article for my 2007 addin deployment..