As you might have noticed, I have been absent from this blog from the last couple of months. Not that I ran out of topics or I don’t want to share my opinions, it’s just “life got in the way”. Putting it bluntly, my priorities shifted so I choose to spend more time doing other tasks. Obviously, I could spare a few minutes here and there to write a new blog post, but sometimes you just need a long period of reflection to observe and rethink what to do next.
OpenSSL became publicly known (unfortunately) for the wrong reasons. Their development team got the typical backlash that System Administrators usually get: if everything is working fine nobody cares, as soon as something bad happens everybody loses their mind. I'm obviously talking about the Heartbleed bug. Before Heartbleed was found, it was estimated that 61% of all Apache servers used OpenSSL to handle TLS/SSL connections. As soon as it was found a lot of people freaked out. Successfully using this exploit could allow an attacker to read a target server memory, extract its private key and ultimately mount a man-in-the-middle attack . On the other hand, OpenSSL development team consisted of 11 contributors and a budget of less than $1 million a year (most of it from donations). In a world where even large Corporations, with almost unlimited resources, consistently release buggy software, a team of eleven developers should be allowed to make a few mistakes.
The first step of any robust development workflow relies on a structured and well-defined build process. Having a manageable build process can spare your development team from wasted time, headaches and unnecessary complexity. If you're handling a handful of projects with low compilation overhead, this particular topic might be irrelevant to you. Today's article is mainly targeted for those who must work with multiple projects, of different kinds (Web applications, Scheduled tasks, Console applications, Mobile application, database script, so on) and deploy multiple artifact types.
Here's another quick tip for anybody interested in protecting sensitive information declared on your Web application web.config. In this example I'm going to use Windows Data Protection API (DPAPI) to encrypt connection strings and session state SQL connections string on all web.configs found under 'C:\inetpub' (default location for web applications running on IIS).