... is the worst possible thing you can be.

One of the aspects of the work that I do is system analysis. I'm contacted regularly by individuals who are working on a new application or have an application that's about to go into production that they want me to look at. Generally, the focus is performance or scalability, but there's almost always a "is it secure?" comment in there.

Today begins my coverage of ZendCon 2007. This is the first entry and covers Day 0... the Tutorials.

Today started with a $4 muffin. As the first day of festivities but not yet the conference, breakfast was not available. Hence, the muffin and a flock of slightly annoyed geeks.

When I checked in at the registration desk, I got one of the best surprises so far. Last year Zend put together a deck of cards featuring prominent PHP'ers. This year they got even more creative went with trading cards featuring the speakers and other prominent PHP'ers. I happen to be one of them... BarCampDC was the first time seeing CaseySoftware, LLC on shirt, this is the first time seeing myself on a card. Sounds odd but kind of fun. I'll attach the card once they're available online.

The tutorials were an extended format. Two three hour sessions with a deep focus on a single topic. There was the standard Zend Certified Engineer Crash Course by Chrisitan Wenz, an Extending PHP session given by Wez Furlong and Sara Goleman, a Security Crash Course by John Coggeshall, and finally PHP Development Best Practices by Matthew Weier O'Phinney, Mike Naberezny, and Sebastian Bergman. I attend that last one last year, so I opted for the Security Crash Course.

Updated:  See the alternative fix below... 

In the past 24 hours, I've received numerous panicked emails from dotProject users about the Cross -Site Scripting Vulnerability announced yesterday. True, it is something to be concerned about and it should be addressed. True, it could cause problems for some users.

Unforuntately, these same people seemed to have missed that this has been fixed since the first 2.1 release candidate which came out four months ago. This type of issue was identified to us prior to that time and concrete steps were applied to completely close holes such as this. I know because I helped apply those changes and have been heavily involved in encouraging people to upgrade as soon as possible. In fact, it was due to those security changes that the latest version of the Project Importer - released over a month ago - doesn't work with any version prior to the 2.1 Release Candidates.

Chris Shiflett recently wrote on the inherent problems that go along with disclosing bugs in web applications (specifically security holes). I believe he took the responsible route of reporting the issue privately, waiting an appropriate time, and then releasing the details publicly. In his case, the "appropriate time" was a year, Amazon appears to have effectively reduced the potential damage of the issue, and everyone is sleeping soundly at night... but what if it didn't go so smoothly?

As I write this, I'm reviewing some of the latest and greatest patches for the applications that I've learned to love. Drupal, SugarCRM, dotProject, Mediawiki, and some secret sauce form the foundation and almost the entire infrastructure of CaseySoftware. More importantly, they form the foundation of almost every project since we began just over two years ago. Therefore, I couldn't let Stefan Esser's "Month of PHP Bugs" pass unmentioned.