There has been a bunch of questions regarding the differences between CoApp and OpenWrap when it comes to versioning. If you follow the blogs and that project, you know that they are planning to install everything in the GAC whenever packages are installed, and require everything to be Authenticode signed.
OpenWrap takes the opposite view, and discourages strong-naming your assemblies. The reason is very simple: in .net, whenever you update an assembly to a newer version, as long as the assembly is not strong-named, the assembly version is blissfully ignored, which lets people swap the dll around as and when needed, when there’s a fix / update available.
The only way to not break project references when packages are updated would be to never update the AssemblyVersion in an assembly, rendering the versioning scheme useless.
The alternative is to create policy redirections as part of the deployment to the GAC of a strong-named assembly, or for the consumer to add those redirections manually in each of their projects. Either way, it’s either a huge burden on publishers (and people don’t bother), or on the consumers (and people get angry). Either way, we’re still in unhappy land.
All this versioning is not needed, for the simple reason that OpenWrap has its own versioning scheme, per package, providing you with many more features than the 1-1 coupling provided by strong-named assemblies.
And finally, last but not least… If like me you believe very strongly in xcopy-friendly development and deployment, the GAC breaks all this: you now require the assemblies to be GAC’d on your build server and locally before you can use them, as otherwise any odd version already installed on the system would take over. And there lays the major pain point, the GAC takes over from your local references and there is *nothing* you can do about it.
As the goal of OpenWrap is to enable rapid development and update of packages, strong-naming assemblies and GAC’ing them is diametrically opposite to the vision of the tool, and as such will be discouraged. I’ll even put a big fat red warning if you take a dependency on a package that has assemblies already in the GAC, offering you in one swoop the option of removing them interactively. I may even provide the option to automatically strip out strong-naming from assemblies you try to package.
Help yourself and help versioning, say no to the GAC. If you do have scenarios where you believe strong-naming is the right solution, please leave a comment and we can discuss it.
[Note: Strong-naming has nothing to do with signing. Signing assembly code with a certificate is not useful to reduce malware (I don’t see how it would), and it pauses the risk of the certificate revocation being checked before being ran. But it has nothing to do with the key signing used in strong-naming, it’s a different process.]
13 comments:
Great post man! I think we all feel the same about the use of the GAC.
The only thing I would point you to is Reflexil. Malware that makes it easy to push your changes into DLLs. http://sebastien.lebreton.free.fr/reflexil/
"Reflexil is able to manipulate IL code and save the modified assemblies to disk. Reflexil also supports 'on the fly' C#/VB.NET code injection."
Can't do it to strong named assemblies without having the key for the strong name. Kind of scary.
I wouldn't discount strong naming, just the use of the GAC.
I think R's comment above regarding Reflexil demonstrates clearly why signing code is beneficial for killing off malware threats.
Actually, no, it certainly doesn't.
You have write access to the binaries. You can simply rewrite the exe. Or strip all the strong-name signatures and rewrite the assemblies. But at that stage, you're already running code, why go through the trouble? Just execute whatever code you want. I just don't see an attack vector that somehow would be prevented by strong-named assemblies. I don't see the vector of attack as being valid.
It doesn't provide for verifying who signed the strongly-named assembly either, as all keys are self-generated, and don't contain any author info.
THe only thing that sn ensures is that your code, provided it is not rewritten by any one, doesn't accidently load an assembly it didn't know about, so it prevents spoofing. But if you have write access to the app loading the assembly, you can already rewrite the whole thing...
There will be package signature in OpenWrap, where an author can sign their package, which will be verified at install-time. Then it's easy to verify that the assemblies come from the package.
If executing code is on the box, your system is already compromised. Signatures and strong names are irrelevant at that point, I agree.
I was thinking more along the lines of malicious code attempting to piggy back off an assembly. The assembly would be altered and therefore wouldn't execute.
Assemblies that aren't strong named/signed pose the risk of executing code that latched on during transit. No?
Well if it's in transit between the server and the client, then packages will be signed and verified before being installed, so there is no risk there... Package is signed by developer's key, developer's key is signed by OpenWrap's server, OpenWrap's key will be part of the client.
Well, that just verifies the envelope wasn't tampered with. Once that's opened, there's no guarantee the contents weren't altered with. Or did I misread something?
I don't think i understand the scenario. In OpenWrap the packages are always there, so verifying various components come from that package is trivial.
If someone wants to go and muck around with binaries for which they have write access, nothing can prevent that.
What is it you want to verify and at what point? The signature of the author? The strong-name? What vector of attacks, beyond where an attacker has write access and already runs code, are you trying to stop?
生存乃是不斷地在內心與靈魂交戰；寫作是坐著審判自己。............................................................
Quality is better than quantity...................................................................
Well I think the point people are trying to make about signing is that:
- if you sign an assembly, and I trust you...
- and I don't trust Bob...
- and Bob sends me the assembly which was signed by you...
- then I can happily use that assembly because I know Bob couldn't have altered it...
Anyway not really something I have ever worried about, and I it's think a concern which is orthogonal to versioning and package management.
Agree with all your points - GAC is almost as evil as COM, and policy redirects are the work of the devil. This is stuff should be reserved for legacy scenarios only.
Words are not living in dictionary. Words are living in mind...................................................................
快樂，是享受工作過程的結果..................................................
一個人的價值，應該看他貢獻了什麼，而不是他取得了什麼....................................................
Post a Comment