Struggling With My Inner Code Nazi

How a code nazi responds to the build breaking

Mark Flory — Wed, 15 Apr 2009 15:39:02 GMT

Safari Books Online Review

Mark Flory — Thu, 26 Mar 2009 18:06:37 GMT

In August of 2006 I was listening to the radio and stumbled across a guy named Dave Ramsey. The simplest way to distill Dave Ramsey down is: Get out of debt, stay out of debt, live beneath your means.

Before long my wife and I were both on board with it and we were budgeting and cutting our expenses. This created a really big problem for me because my wife had been waiting for a long time to intervene on my addiction. The budget gave her the perfect excuse.

My drug of choice...Technology books.

I used to go the library and just peruse the Technology section and ponder what book will be my choice. I bought at least one a month, and usually two. I almost always read them.

My wife hated that I "wasted" money on them. But all that knowledge in one place, hard bound, and shiny was impossible for me to resist.

But now I had a problem. Our agreed upon personal spending limit was going to be severely damaged by my book habit. If I continued on this track it was going to damage my other spending habit, eating out for lunch. There had to be a way.

At first, I tried the used book store.

The used book store is a great place to get cheap books on any subject, as long as that subject is a little out of date. In our world a little out of date is a lot out of date, bordering on useless. For example, I found a really great Prolog book, which I bought (I am not an addict, I do not have a problem), but try finding a good .Net 3.x book and you are going to be out of luck.

This was not the answer.

So I tried the library.

It was as bad or worse than the used bookstore. You trade free against cheap but you add on a time limit.

Still not an answer.

But then I remembered a trial I had done of O'Reilly Safari Books online. I had signed up for the trial, perused one book, and then went back to my hard back ways. But maybe Safari could be the methadone to my heroin a good substitute.

I was wrong. It was better.

Compared to the original drug it was more flexible, far cheaper, and does not take up nearly as much room in my basement.

I now have thousands of titles to choose from and 75-100 new ones every month.
I could dabble in a book, taking just the pieces I needed, without having to pay for the whole thing.
Once I was done I could jettison the book from my shelf (after a month) and put another in its slot. It did not sit around and gather dust.
I could search through tons of books and quickly pull up sources from one book to another.
I no longer had to haul all of my "core" books with me to work.
I could explore into other areas without worrying that I might not like what I find.

The only negative:

It is not as easy to read while you are taking a bath. I like a nice hot bath and a good book. And yes, I prefer bubbles.

I have survived though (I read fiction instead).

Some would make the argument that all the information you could want is available somewhere on the Internet.

Now, I consider Google a close, personal friend but I have to say he has some shortcomings. The main one is, although he does know everything, he keeps that knowledge flung all over the place. It is difficult and time consuming to get it all together in one place. Even if you do, the resulting information is often less than coherent.

So, for my money nothing beats a book, especially for learning something new. A Book will concentrate on one subject and do so with, generally, a unified voice.

Except for my money I don't want a book, I want access to thousands.

Specification of My Garage Door

Mark Flory — Thu, 29 Jan 2009 21:09:07 GMT

This morning I got up in the bitter cold to walk our new puppy. I did not want to do it, but if he does not get his exercise in he turns into a total spaz by the end of the day (instead of just a partial spaz).

When we were done walking I opened up my garage door to get back into the house using the keypad. Because it was so cold I was not patient enough for the door to go up completely before I went inside. Because it was so cold I had my hood pulled up so that my peripheral vision was completely shot. Add the two things together and you end up banging your head into the garage door.

Somewhat like this:

One thing I noticed is that when I broke the beam of the safety sensor it did not stop the door. If the door had been going down and I had done the same thing it would have stopped. For some reason this gave me a pause and made me think about the way software is specified.

I began to imagine a meeting long ago in some garage door manufacturing companies corporate office. It was your typically design meeting, guys in suits sitting around talking to a bunch of guys in Dockers.

“Look fellas”, said the main guy in a suit “we have this problem.” Here he would have paused to make sure he had their attention.

“People keep getting squashed by our doors. It’s a real issue. The shut the door and then walk under them, or their idiot kids do, or their idiot dogs, or their idiot Subaru hatchbacks do.”

“Or their grandmothers”, pipes up one of the guys in suits, the obvious suck up.

“Right”, says the main suit “So what we want you to do is to work up some kind of laser that when it gets broken it causes the door to go into reverse and stop squashing people.”

“Like bugs”, adds the suck up.

“A laser?”, asks one of the Docker’s kids.

“Yeah, you know, like in the movies where they rob the art gallery and cross the laser and the whole thing comes crashing down.”

“Like Entrapment”, says suck up, who then glazes over as he thinks about Catherine Zeta Jones.

“Exactly!”, says Mr. Main.

At this point a lot of the Docker's brigade is mad because the suits are trying to tell them how to solve the problem. Of course, it is pretty much exactly how they are going to do it, but still where do these guys get off telling them how to do that. And it is not a laser, it is an optical beam. But for all the grumbling they get to it.

On the first iteration the Docker crew does exactly what is asked. The plane of the “laser” gets crossed and the door throws itself into reverse. Except sometimes the plane gets crossed when the door is going down, which is great because it caused the door to go back up. However, when the door is going up crossing the plane causes it to shut without any way to stop it. So they go back to the drawing board and decide that what it really should do is just stop.

And then one brilliant engineer says “You know, there really is no reason to stop the door if the door is going up.”

And thus instead of giving myself a violent whack and knocking my storm trooper helmet all askew, I really just got a glancing blow. And even better the door did not reverse itself and squish me and/or the dog (although at this point I might have been ok with the latter).

I guess my point is: Specification is hard, let’s go shopping.

Security by Obscurity

Mark Flory — Wed, 28 Jan 2009 15:25:48 GMT

If you read enough about security in general you will hear the often touted principle of do not rely on security by obscurity. It even has its own Wikipedia page.

You see this advice thrown out a lot when somebody does something like embedding encryption keys in their code. The developers assumption is that the code will never be read by anyone and thus the key is safe. I have personally seen that one cracked in about one minute.

So the advice is good, you should not RELY on security by obscurity. It cannot be counted on.

However, does that mean you should never use obscurity at all?

A common example is code obfuscation. A lot of people will tell you there is no point because someone determined enough, or good enough, or who just has a lot of time to waste will be able to break it down. So absolutely, you should not rely on obfuscation to secure your application (i.e. key hiding).

But my immediate thought is: Why make it easy for them?

Why not cause them more hassle, even if it is not all that much. What is more, the additional hassle onto itself will serve as a deterrent for the less determined, or talented, or patient.

So I believe you should assume that any information you obscure will end up in the attacker’s hands no matter what you do. But, if there is nothing you can do about it (such as somebody reverse engineering your code), then you should obscure it anyway just to be a pain in their ass. It is not like they are going to thank you for making it easier for them.

Finding a performance issue with dynaTrace

Mark Flory — Mon, 29 Dec 2008 20:30:30 GMT

Recently, I was asked to look into a performance issue we are having with a particular windows service when it is being communicated with a MMC snap-in we have developed. Essentially the snap-in communicates with the service using WCF to get the data that populates a particular form. When the form was loaded it could take between 10-30 seconds depending upon the data storage mechanisms on the backend.

Normally, figuring out what is going on with a Windows service can be a huge pain in the ass. Everything is being tossed out on a seperate thread and you have to figure out what causes it to do what and what else is going on.

Fortunately, I have dynaTrace on my side!

So first thing I need to do is select my applications for instrumentation using the .Net Configuration Tool:

This basically lists every piece of managed code ever JIT'ed on my box. What was interesting to me is that I do not think the Microsoft Management Console (mmc.exe) is managed code. But, because it loads up my managed code it shows up in the list. Because of this I could see what is happening on the console side.

I also chose to instrument the Windows Service as well. The next thing you need to is determine the specific set of methods that are interesting in this scenario. Doing this is no small trick and deserves a post onto itself so in the end I had this being reported in dynaTrace.

The big contributed here was the code in the namespace that took 39 seconds to execute, but that is not what I am going to focus on for this article. While the developers were chunking on the code causing those issues I also noticed the GetDefaultCertificate code was taking 3 seconds or so.

The code is basically something like this:

internal static X509Certificate2 GetDefaultCertificate()

{

string certString = GetCertificateSetting();

if (string.IsNullOrEmpty(certString))

{

return null;

}

byte[] bytes = Convert.FromBase64String(certString);

X509Certificate2 cert = new X509Certificate2(bytes, "");

return cert;

}

My code Nazi alarm goes off immediately because this code should definitely be a property (if your method is named Getwhatever that is usually your first clue).

Leaving that be though, the thing I now know, because of dynaTrace, is that this psuedo-property is accessed 56 times, but does it really need to new'ed up each time?

Turns out that it does not. That the certString never changes through the course of an execution (it is held in an App.Config which cannot change). So this values should be set once and just referred to again and again like so:

        internal static X509Certificate2 GetDefaultCertificate
        {
            get
            {
                if (m_certification == null)
                {
                    string certString = GetCertificateSetting();
 
                    if (string.IsNullOrEmpty(certString))
                    {
                        return null;
                    }
 
                    byte[] bytes = Convert.FromBase64String(certString);
 
                    m_certification = new X509Certificate2(bytes, "");
 
                }
                return m_certification;
            }
 
        }

A very minor code change. But one that would have been very difficult to see as necessary without dynaTrace pointing it out to me.

Diagnostic tracing your application with dynaTrace

Mark Flory — Wed, 24 Dec 2008 15:48:50 GMT

My company recently purchased a software called dynaTrace to be used for performance diagnosis. It primarily started as a Java tool but they do support .Net as well. Since my company is entirely .Net based I will explain the product from that point of view.

The application works by using MSIL injection to put essentially a header and footer into each method you have instrumented in an application. If you do not know what MSIL Injection is here is a great overview on the PostSharp website, and here is a more detailed but not as accessible explanation of how to do it.

So as your applicaiton is running each instrumented method reports back to a diagnostic server which collects all the method calls and then strings them together. There is a client application that connects up to the server and lets you see what is going on in a particular execution. Each seperate transaction flow in your application, what dynaTrace calls a purepath, is knitted together so you can follow it all the way through.

The product can follow across web service, MSMQ, and remoting calls so that everything is seen together as one transaction. The current version cannot do WCF but their next release (hopefully 1st quarter 2009) will.

So, let's say you had an instrumented ASP.Net website that when some user makes a request, it calls a web service which is also instrumented, which then contacts the database. With dynaTrace we would see that as one request, it would be relatively transparent when the code executed across to the web service. The calls the web service makes to the database are seen because ADO.Net is instrumented, but the database server itself is not directly instrumented.

So now I can see the total time of the web request , all the pieces of it, and what database calls are made. With that information you can figure out what the big contributers are very easily.

SafeCode's Fundamental Practices for Secure Software Development

Mark Flory — Tue, 09 Dec 2008 15:23:28 GMT

Several blogs I follow have mentioned that SafeCode has released there Fundamental Practices for Secure Software Development guide. I had thought that this was released a while ago actually and the document is dated October 8th. Oh well, it is a good reference regardless.

The mission of SafeCode.org is "SAFECode is dedicated to increasing trust in information and communications technology products and services through the advancement of proven software assurance methods." They have a number of different organizations contributing to this effort, like Microsoft, EMC, Symantic and others.

I got to it by reading this article Secure Software Development Practices 'not rocket science'.

Microsoft's SDL Optimization Model

Mark Flory — Mon, 08 Dec 2008 18:49:14 GMT

Microsoft's SDL Optimization model is for moving your organization along in their Security Development Lifecycle. The SDL is really born out of a lot of lesson's learned and pain realized by Microsoft over the years. The idea is to build into your development process a more security centric focus throughout the lifecycle.

The Optimization Model follows this diagram:

The idea here is to first determine where your organization is at, figure out where you want to be, and determine how to get there. You start with an introduction document and move from there to a self-assessment. Depending up on the assessment you will move on to an implementer's guide.

What I find helpful about this is it is difficult to figure out how to move an organization towards more secure development. It is very helpful to have a demonstrable process that worked for somebody. The fact that it came from Microsoft's own experiences and they are very enthusiastic about their success with it helps a lot.

It also hurts a little because they have already lined up a number of vendors, their SDL Pro Network, to evangelize the process (i.e. sell services and training). Don't get me wrong I am all for making a buck but sometimes it can get a little tedious how much they are promoting it within their documentation.

I believe at some point it will be almost a requirement for software vendors (of whatever stripe) to have a demonstrable secure development process (for example the PA-DSS). Too much money is being lost, too much information is at risk, and something definitely has to be done. I am not positive that Microsoft's SDL will emerge as the solution for this but at this point it is better than nothing.

Using closed Generics (or hey, everyone, this is how I am crazy)

Mark Flory — Tue, 26 Aug 2008 16:12:13 GMT

I was reviewing some code the other day that was violating one of our metrics and I saw something like this:

internal class UtilityClass{

public static string SomeUtilityMethod(IList<SomeClass> someStuff)

The thing that struck me is this was an internal class and this was the only public method. So the only purpose this class serves is to perform one operation on this closed generic IList.

To me it is more natural and far oop-ier to have that code be part of the collection itself. That may have been the natural instinct of the developer as well but they felt stuck because they are using generics. The more I thought about it using closed generics like this seems problematic.

For example, if I have two lists say:

IList <String> blah;

IList <String> someOtherThings;

And this method:

public static void BlahProcessor(IList<string> blahStrings)

Are those two lists the same thing? Can we treat them the same? Is the list someOtherThings meant to be sent to the method BlahProcessor?

The code as written cannot answer these questions. Someone looking at this kind of code would have to make a determination and, of course, they could make a mistake when doing so.

So what I should be doing instead is creating a new class that inherits from the closed generic that I am using, like so:

public class BlahCollection : List<string>

And now my method will look like this instead:

public static void BlahProcessor(BlahCollection blahStrings)

Now I know that the method is meant to only work on a specific collection of strings. Yes, we did create an extra bit of code but that code is now definitive and purposeful in a way that it previously was not.

I imagine if this was how the original collection had been stated this way in the code then the problematic utility method would never have been created. The developer would have just realized that the collection itself should encaspulate this operation.

Hey look, at least one other person thinks the same thing as me: http://aspadvice.com/blogs/rbirkby/archive/2004/05/10/2405.aspx