Thanks Glenn, Use of the GAC has always had a cloud of confusion around it. However, the GAC is a great tool for version control of assemblies. It might also be worth mentioning that for web access of assemblies leverages the GAC as well for client side execution. You can expose COM interfaces in your .Net assemblies, place them in the GAC, and access that interface via the object model in JavaScript. Use it before for certain .Net enabled thin client development models. The GAC also has some CAS implications, though I find very few folks make use of CAS.
Jonathan -----Original Message----- From: GlennDoten [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 8:38 AM To: Log4NET Dev Subject: Re: Strong name private key policy Couldn't have said it better, Jonathan. Except that to my mind the defence against the types of attacks you mention is more important than whether the assembly is in the GAC (for the purposes of saving memory). Sometimes an assembly must be in the GAC (BizTalk is a good example), but I think the signing, like you mention in your second paragraph, should be done to all the assemblies you produce. The CLR *always* look in the GAC first to find a type. The working directory is only searched during link time (via csc.exe). It might be worth mentioning that the primary reason the GAC was invented is to allow side-by-side execution of different versions of assemblies, with the same file name. So you could have two versions of log4net.dll: one with 1.0.0.0 in its metadata and one with 2.0.0.0 in its metadata. The CLR will find the correct assembly from the GAC. -glenn- On 6/22/06, Jonathan Wiggs <[EMAIL PROTECTED]> wrote: > > Good morning, > > I wanted to at least throw in on this conversation as I've been working > with .Net and security for almost 7 years at this point. Yes, since the > early Beta. A signed assembly is only a requirement for placing an > assembly in the Global Assembly Cache, not the other way around. People > who are interested in this process should look up the .Net Assembly > Discovery Process to see how .Net looks for assemblies at run time. The > first place it does check is the GAC. So if you have a signed assembly > there that's what will get run, after that it does check your run time > directory of the executable. > > I would highly recommend signing your assemblies though; it is really > considered a basic step in securing your .Net application. This in > conjunction with security link demands when calling between assemblies > is the only way to prevent attacks such as Man in the Middle and > Assembly replacement. > > Just my two cents. > > Jonathan L. Wiggs > > Software Engineering Manager > Envision Telephony Inc. > ________________________ > Office: 206.225.0800, ext. 236 > Cell: 206.387.7860 > [EMAIL PROTECTED] > www.envisioninc.com > > -----Original Message----- > From: GlennDoten [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 22, 2006 7:20 AM > To: Log4NET Dev > Subject: Re: Strong name private key policy > > Hi Tom. I work at PC Connection and we've been using signed assemblies > with .NET 1.1 for two years now, and they are in the bin directory and > not GACed. They don't need to be GACed. Keep in mind that an signed > assembly is no different than a non-signed assembly except, of course, > it has a public/private key pair embedded in it. But this has no > effect whatsoever on whether the assembly is run from a bin directory > (whether ASPX or not) or whether it is run from the GAC. > > From that blog entry: > > > As you probably already know every asp.net application lives in its > own application > > domain (a unit of isolation inside an application) > > To be precise, it should be a "unit of isolation inside a process." > > > This is true for all assemblies that are not strong named. For > example, you wouldn't > > want System.Web.dll loaded up into each application domain as it would > mean that > > System.Web.dll would be loaded once for each application, bad bad > bad!!! So strong > > named assemblies, irrespectively of where they are loaded from are > loaded into a > > shared domain (they are domain neutral). > > This paragraph really doesn't make sense. The reloading of signed > assemblies in the bin directory (so long as they are not in the GAC > also) occurs just the same as it does with non-signed assemblies. Try > it. We've been doing this exact thing for a long time. > > Then she mixes a GACed assembly (System.Web.dll) with other assemblies > that are signed but not in the GAC. Bad, bad, bad! This is comparing > apples and oranges. And signed assemblies are most definitely *not* > loaded into a shared address space (and I don't know what "shared > domain" and "domain neutral" means here--GACed assemblies are in > memory only once, not per app domain or anything like that). > > > For these reasons it is not supported to store strong named assemblies > in the bin > > directories of ASP.NET applications in 1.1. > > That's just plain wrong. It works fine in not only 1.1 but 1.0 also. And > in 2.0. > > A Chris who replied to her blog points to this article: > > http://www.gotdotnet.com/team/fxcop/docs/rules.aspx?version=1.32&url=/De > sign/AssembliesShouldHaveValidStrongNames.html > > This is exactly why you want to sign assemblies. The primary reason is > not so that they can be GACed (although that is certainly necessary at > times) but so that the assemblies can be trusted by a client. Not only > do signed assemblies work just fine without any of the supposed > problems this blogger points out they also work just fine in the bin > directory of a console app and/or a Windows Forms app. Been doing both > since .NET 1.0 with no problems at all. I also know a lot of web site > developers that also keep their signed assemblies in the ASPX bin > directory. > > So I have years of empirical evidence refuting how signed assemblies > work. Jeffrey Richter's books are extremely good at describing how all > this works and it's even supported. > > Hope this information proves useful. > > -glenn- > > On 6/22/06, Whitner, Tom <[EMAIL PROTECTED]> wrote: > > Glenn, > > > > Please refer to the following articles - > > > > http://support.microsoft.com/?kbid=324519 > > http://support.microsoft.com/default.aspx?scid=kb;en-us;813833 > > http://blogs.msdn.com/tess/archive/2006/04/13/575361.aspx > > > > These all indicate that running ASP.NET applications with > strong > > named assemblies deployed to the bin folder is not supported in .NET > 1.1 > > or 2.0 as well as some of the symptoms might be experienced. > > > > Thanks, > > Tom > > > > -----Original Message----- > > From: GlennDoten [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 21, 2006 10:19 PM > > To: Log4NET Dev > > Subject: Re: Strong name private key policy > > > > Not true, Tom. Just because an assembly is signed does not mean it > > must be in the GAC to be used by ASPX. We run non-GACed, signed > > assemblies with ASPX in production all the time. > > > > FYI > > > > On 6/21/06, Whitner, Tom <[EMAIL PROTECTED]> wrote: > > > We are facing a similar question with some internal code. We have > > > decided, at least for now, to produce both strong named and > non-strong > > > named binaries. Most agree that the strong named option is > preferred. > > > However, due to ASP.NET'sbehavior when loading strong named > assemblies > > > (i.e. it requires the GAC), not all individuals can/will tolerate > GAC > > > installation on highly locked down server. Hence, having the > > non-strong > > > versions has become a necessity. > > > > > > - Tom > > > -- -glenn- ___________________________________ Google Talk (Jabber): [EMAIL PROTECTED] ICQ: 153149689 Yahoo Messenger: gdoten MSN Messenger: [EMAIL PROTECTED] IRC: ostinPowers Skype: [EMAIL PROTECTED] ___________________________________
