Olivier Langlois's blog

After having reported the bug to MySQL and after a lot of patience trying to explain it to the MySQL developers, they have finally verified the validity of my bug discovery and have classified it as serious!!

For the gory details of my discovery, you can consult the bug report.

I have not found this book very fun to read because of its very structured and academic format. I have not learned much from it as much of its content is general wisdom that anyone with many years of experience in the industry has probably seen around before. Something positive I can say about the book is that I totally adhere to the methodology explained in the book. In my software development career, I have experienced myself the benefits of applying similar software development management methodology and I have also seen the negative consequences of not following it.

I have not found this book as interesting as the type of books that I usually read. I prefer books dealing with the more technical aspects of software development. I have read this book because I need to acquire a solid base of knowledge on software project management and not because the topics covered in the book seemed fun and interesting to me. Even if I was not very enthusiast to read it, I must confess that the author made a great job making his book interesting to read by interleaving important concepts with anecdotes from his work experience.

This book is divided into 54 short advices each taking 1 to few pages to expand the rational behind the advice. This is a format that I like and the advices that I have preferred were the ones dealing with the psychological aspect of software development. An example of such rule is that software quality is the mirror of the state of mind of the team. For some this might be obvious but considering the book intended readers which consist of engineers and software professionals, the author has been wise to be explicit on this topic in my opinion as from experience, human interactions is usually not the strongest skill among developers.

The part that seems to me to be outdated is the whole proposed economical model to market software. The author advocates that to make money from software, you must release often like every year and by doing so, your customers will be so happy that they will gladly hand you more money year after year. I think this model used to be true when the software industry was still young 20 years ago but in 2008, the software products are so mature that no matter how hard you try to squeeze more new features, it will not be enough to justify for people to purchase the new version when that last one does everything you want. You just have to think about the sales of Windows Vista or Microsoft Office 2007 to see what I mean. Changing just for the sake of changing does not sell.

In my opinion this model should be changed to one where incremental small evolutions are proposed to customers. I would be willing to pay a small amount of money every year for an OS that is smaller, better and faster at each version. I do not get it how software companies can expect people to be interested in slower and more bloated products than the previous version. Add the possibility to purchase inexpensive add-ons to fill very specific needs to the model and you have a very attractive model. I am not sure if what I would like to see is representative to what the typical customer expects or if my proposal is viable in real life but one thing is sure. The model proposed in the book does not seem to work anymore for many mature businesses.

There is a 2006 edition of this book. I might take a look in it to find out if the advices that I have found outdated have been reworked.

This is a good book as it does a good job covering the different sources of software insecurities:

• The classical buffer overflows on the stack and on the heap
• Canonical issues on input
• The least privilege principle
• There is a brief overview on how store a secret

On the last point, the authors know well the topic. If you are using cryptography to protect something in your software but just store the private key in a global variable then you are helping tremendously the job of hackers as all they will have to do is look into your executable binary to search for something that looks like a key. A security measure is as strong as its weakest element and no hacker is foolish enough to attack a cryptographic algorithm that is proven strong. Even if you store the key in a secure place, all that is needed to retrieve the key is to perform a memory dump at the right time just before the software use the key. At least, you can make hackers job harder as there is nothing you can do to make your software 100% safe against hacker if the software is valuable enough to motivate them to hack your software. All you can do by improving your software security is to buy you some time before your software is hacked. All that to say that there is no bullet proof solution against hackers but the book gives solid leads to improve software security in that aspect.

In this book, there is a strong emphasis on Microsoft security technologies. The Windows Crypto API and the Microsoft OSes privileges API are described in length. If you develop on Windows and want to make your software more secure then this is an excellent book for you. If you develop on another platform, there is still something for you in this book as there are a lot of code snippets that are platform independent to improve software security such as input validation for file names to protect yourself against canonization bugs.

This is a very good book about software security but I do not recommend it simply because there is a new edition of it.

The name has been coined by Bjarne Stroustrup and is using the property that an object constructor and destructor will always be called at the beginning of the object existence and when it will goes out of scope. This is guaranteed by the language itself and the object will be destructed no matter how it goes out of scope. It could be by exiting a function or when the stack is unrolled by an exception been propagated out of the stack.

The RAII consists of encapsulating a resource (be it a file handle, a lock or a pointer on an object allocated on the heap) in a class. The resource acquisition will be performed in the constructor and then the C++ rules governing the lifetime of an object will take care of releasing the resource by calling the class destructor. It is to support that technique that the class template auto_ptr has been included in the standard library.

The technique has 2 purposes:

1- Simplifying code

Traditionally, it has been very error-prone to perform resource management from a function having many exit points. Suppose the following function:

void foo()
{
  // Acquire resource A
  // Do some processing
  if( error )
  {
    // release resource A
    return;
  }
  // Acquire resource B
  if( !B )
  {
    // release resource A
    return;
  }
  // Do some processing
  // Release resource A
  // Do some more processing
  // And finally, release resource B
  return;
}

Now imagine that this small game of resources tracking spans over more than a hundred lines of code and that you have dozen of resources. This is a waste of energy and chances are that there will be a resource leak in this type of code. If it is not today, it can be during the next maintenance of the function in few months or years where you will need to add another exit point in the middle of that type of function. The best way to handle this is with RAII. Once you acquire the resources, you can forget about them as they will be automatically released when the code will exit the function. As an added bonus, it will simplify the code as all the statements for releasing the resources are not needed anymore.

2- Make it easier to achieve exception safety in functions and particularly in constructors.

When an exception is thrown from a constructor of a class acquiring resources, the hard and error prone way to make sure that no resource are leaking is to place the constructor code in a try block and to manually release the acquired resource in a catch all block before rethrowing the intercepted exception. The C++ language specify that in the event of an exception during the construction, the compiler will generete code to destroy constructed base classes and data members that are objects (raw pointers on dynamically allocated memory does not count) before letting the exception escape from the constructor. Hence again, if you used RAII to encapsulate resource acquired during construction in objects, you will not need to worry about releasing them as the compiler will handle this for you.

One detail worth mentioning is the RAII is not an applicable idiom in some other OO programming languages. For instance, in Java because of its garbage collector, there is no guarantee from the language when objects will be destructed. It will just happen eventually after objects goes out of scope once the garbage collector recuperates the unused objects.