Posts
11
Comments
6
Trackbacks
0
Wednesday, April 15, 2009
How a code nazi responds to the build breaking
Check it out on {codesqueeze}.
posted @ Wednesday, April 15, 2009 10:39 AM | Feedback (0)
Thursday, March 26, 2009
Safari Books Online Review
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.
posted @ Thursday, March 26, 2009 1:06 PM | Feedback (2)
Thursday, January 29, 2009
Specification of My Garage Door

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:

Stormtrooper-Bumps-His-Head

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.

posted @ Thursday, January 29, 2009 3:09 PM | Feedback (1)
Wednesday, January 28, 2009
Security by Obscurity

 

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.

posted @ Wednesday, January 28, 2009 9:25 AM | Feedback (2)
Monday, December 29, 2008
Finding a performance issue with dynaTrace
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.
posted @ Monday, December 29, 2008 2:30 PM | Feedback (0)
Wednesday, December 24, 2008
Diagnostic tracing your application with dynaTrace

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. 

posted @ Wednesday, December 24, 2008 9:48 AM | Feedback (0)
Tuesday, December 09, 2008
SafeCode's Fundamental Practices for Secure Software Development

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'

posted @ Tuesday, December 09, 2008 9:23 AM | Feedback (0)
Monday, December 08, 2008
Microsoft's SDL Optimization Model

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:

Microsofts Security Development Lifecycle Optimization Model

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.

posted @ Monday, December 08, 2008 12:49 PM | Feedback (0)
Thursday, September 04, 2008
Generating VSTS 2008 Coverage statistics

I needed to be able to execute automated unit tests essentially command line for several different projects I am involved in.  That is easy enough to do with mstest.exe (I am using FinalBuilder so it is even easier than that).

What is not so easy is to gather the corresponding coverage statistics in something useful (i.e. XML).  I need to do that because I use a tool called NDepend to analyze our code base and it only understands the XML coverage file.

It took me a while to get it all figured out so I thought I would blog about the trail of Googling it took to get the info I needed.

First, this article explains how to get mstest setup to create your coverage data and get your code instrumented.  In there is a comment that led me to this MSFT forum post which ultimately led me to Joc's Blog and an article about creating a program to convert the coverage data to XML. 

That is what you need to do but he has a couple of things that won't work (probably because he was working off a Beta of VS 2005).

data.Lines.WriteXml("mylines.xml");

should just be

data.WriteXml("mylines.xml");

And also you need to set CoverageInfoManager.ExePath and CoverageInfoManager.SymPath to the path of the instrumented code.  If you don't set it or set it to the right path you will get this exception:

Error when creating coverage info: Error loading symbol file. Symbol and binary files should be in the same folder as the coverage file or on the symbol path

My code looks like this:

        static void Main(string[] args)

        {

            String coveragepath = System.IO.Path.GetDirectoryName(args[0]);

            CoverageInfoManager.SymPath = coveragepath;

            CoverageInfoManager.ExePath = coveragepath;

 

            // Create a coverage info object from the file

            String coveragefile = System.IO.Path.GetFullPath(args[1]);

            CoverageInfo ci = CoverageInfoManager.CreateInfoFromFile(coveragefile);

 

 

 

            // Ask for the DataSet.  The parameter must be null

            CoverageDS data = ci.BuildDataSet(null);

 

 

 

            // Write to XML

            String coverageoutput = System.IO.Path.GetFullPath(args[2]);

            data.WriteXml(coverageoutput);

 

        }

I was intially confused on what to set those paths to so I set it to where the code was compiled to (/bin).  Eventually I figured out when you set up coverage on code it creates an instrumented version of your code and puts it in a directory off of your test directory.  One directory is called in, and that is where you will find your coverage file, the other is called Out, and that is where you will find your instrumented code.

In case you are not sure how to get coverage instrumented into your code you need to check out this.

posted @ Thursday, September 04, 2008 10:19 AM | Feedback (0)
Friday, August 29, 2008
The marginal bad guy toy

So my wife bought a toy to help my son celebrate his success during potty training.  Jason has recently decided he is a Thomas the Train fanatic so she naturally bought him a train from the series.  When he finally reached one of the milestones she had set we gave it to him.

So I went to open the toy and found out she had bought Diesel.  For those that don't know Diesel is the nominal bad guy.  As a bad guy though he really doesn't rate all that high.  His main trick, from what I can see, is to occasionally shove other trains around and have a bad attitude.

I tried to explain to her that as the mother of boys she needs to understand that certain toys are just not cool.  Diesel is at best a marginal bad guy toy.  He is not Darth Vader, which no set of Star Wars toys made sense without, he was not a stormtrooper, which made good cannon fodder.  He is at best Greedo.  There are just very few times where he makes sense to play with him.

I don't think she got it.

So she still had hope when she gave it to him.

The result was even more surprising than I thought.  He not only doesn't play with Diesel, he has shoved him in a tiny drawer in another toy and gets very upset if you take him out.

posted @ Friday, August 29, 2008 9:12 AM | Feedback (1)
News