Tony Bibbs on PHP

Web Security Demo

Fri, 10 Oct 2008 15:58:58 -0500

Yesterday, on an invitation from our Information Security Office (ISO), I had the pleasure of giving a talk on about injection flaws, Cross Site Scripting (CSS) and Cross Site Request Forgeries (CSRF). That talk had a surprisingly large turnout and crowd participation was good. Anyway, I took my old talk on CSRF and expanded it to include a very simple PHP script (roughly 60 lines of code) that had 2 SQL injection flaws, 2 XSS flaws and a CSRF flaw to boot. I demo'd the flaws (sample input included) and I provided another script that shows some of the fixes you can make to sure it. I've made the slides you see below along with my sample code and the MySQL database available in this ZIP file. For anybody with a working PHP/MySQL setup it would take seconds to stand up and you have something you can play with to see how you can take my simple hacks and turn them into something more serious. Please add a comment below if you find any problems or have any questions.

Web Security Overview and Demo

View SlideShare presentation or Upload your own. (tags: xss sql)

PHP 5.3 on Mac OS X 10.5

Thu, 31 Jul 2008 11:45:28 -0500

Being the recent (and appreciative) recipient of a MacBook I've been getting all the usual development tools installed. Everything went pretty much as expected until I got to where I wanted to compile PHP5. Not just any flavor of PHP5 but a snapshot of PHP 5.3. While this focuses on 5.3 you'd have to do the same song and dance for the PHP 5.2 source. Why?

If there is anything you should gleam from this article for future reference, Leopard comes with a 64bit Apache installation. Thus if I go into the PHP 5.3 source and tried, say:

#>./configure --with-png --with-tiff --with-jpeg \--with-gd --enable-soap --with-apxs2

It my configure, may even compile but when you install and restart Apache you'd get errors about the PHP module being of the wrong architecture. I confirmed this using the "file" command. After that I started down the path of "well, let's just compile to 64 bit". I did find references that suggest trying to add CFLAGS="-arch x86_64" to your configure statement but that didn't work either. You might be able to get this working if you dink with it enough, however, I was in "get it working" mode. I did find this blog post by Marc Liyanage which gives more details into what is going on. Turns out this 64-bit problem is much bigger than just PHP because I was unable to get the fink libraries for stuff like libpng, etc to compile to 64bit. Now maybe you can do this by downloading the individual packages and compiling them one-by-one but I'm far too lazy for that.

The fix? Run Apache in 32-bit mode. Not knowing anything about Mac and that some binaries are compiled to support multiple architectures I was hanging out in #apache on irc.freenode.net trying to figure out the best way to compile Apache under OS X. At the same time I posted to macosxhints.com and got a very simple, elegant answer that didn't require me to download and recompile Apache:

sudo cp /usr/sbin/httpd /usr/sbin/httpd-fatsudo lipo /usr/sbin/httpd -thin i386 -output /usr/sbin/httpd

After that using my standard ./configure worked just fine and I now have PHP 5.3a1 working beautifully. That said, I'd love to hear from anybody that has managed to get PHP 5.3 (and required libraries) compiled using the 64-bit Apache.

Book Review: Pro PHP

Tue, 10 Jun 2008 09:02:00 -0500

On my flight to the DC PHP Conference in Washington D.C. I had a chance to read a copy of Pro PHP: Patterns, Frameworks, Testing and More written by Kevin McArthur. I've never written a book, I clearly don't have a first hand appreciation for the amount of work that undoubtedly goes on under the hood. Given that I will try to be as constructive with this review as possible. First I think it's important to cover the valuable aspects of the book as that will really drive your decision whether the book is worth a read. If you are new to object oriented programming and basic design patterns you will get a fairly good introduction of how to do both in PHP. Part 1, OOP and Patterns, covers things like abstract classes, interfaces, exception handling and a couple of design patterns. The list of valuable design patterns in this section of the books is far from exhaustive so I'd strongly encourage you to supplement what is in this book with a book dedicated to patterns (as well as anti-patterns). One of the best chapters in Part 1 is on Exceptions and I was specifically glad to see Kevin articulate when *not* to use exceptions as it is my experience they are often over used and used improperly. Sort of the square peg in a round hole in Part 1 was a section on what's new in PHP6 which, in my opinion, is a bit premature and it should be noted that some of the features listed in PHP6, specifically the support of namespaces, may actually show up sooner than advertised (PHP rumor mill suggests namespaces may make it into version 5.3 which is further rumored to be out around the first of next year). Because this Part of the book is five chapters yet only 52 pages don't expect a ton of detail on object oriented programming and design patterns, though, you will get a decent introduction.

The order of where things showed up in this book was a problem for me. Part 2 is on Testing and Documentation while Part 4 is dedicated to the Model-View-Controller (MVC) design pattern. At the very least Part 4 should follow Part 1's discussion on design patterns and, better yet, all of Part 4 should have been merged with Part 1. That said, I was pretty happy with the talk on testing and documentation. Kevin does a good job talking through the use of PHPDoc and PHPUnit both of which should be in any PHP developer's toolbox. Part 2 also has a good discussion on Reflection which, back to the organization of the book, could have probably been a better fit in the discussion of object oriented programming, though, he did have a lengthy section on parsing reflection-based documentation data. Kevin did a great job covering the topic of reflection but I was a bit surprised to see no mention of how using reflection can negatively impact performance of your PHP application. Which brings me to my biggest criticism of the book.

With a title like "Pro PHP" I'd expect a few chapters dedicated to performance, scalability and security. While I'm a huge fan of object oriented programming and know a bit about the value software frameworks they often work counter to scalability and performance. This book had no mention of opcode caching, no discussion on application caching, database caching and the use of shared memory (RAM). Maybe that is intended to be another book in and of itself? Nonetheless, having a chapter or two on security is something that is needed if we want to fix the internet. Indeed application security is the subject of many books so I wouldn't expect a book on "Pro PHP" to be exhaustive but today's hackers are trending toward looking for applications holes instead of networking holes because a) they are usually easier to exploit and b) there are a lot of applications looking to be exploited. XSS, CSRF, SQL Injection, etc are all things developers need to be conscious of when writing code (regardless of language) and ignoring security is this book seems to be a bit irresponsible. I know, I know...tough words and, again, you can only effectively cover so much in one book but security definitely should have made the cut.

Part 3 covered the The Standard PHP Library (SPL). This quite possibly was one of the strongest points of the book. SPL's top features are iterators of all sorts, file and directory handling and advanced array handling. Kevin covers all this and more in great detail. I was surprised to learn how many different types of iterators supported by SPL and I would recommend this entire book based on how well SPL was covered.

Part 4 of Pro PHP does a good job covering the most essential parts of the Zend Framework particularly they MVC implementation, logging and access control. In the world of PHP frameworks Zend is becoming more of a household name but I'd simply add that there are a lot of PHP frameworks out there. While the author is clearly a fan of the Zend Framework and does a good job showcasing some of it's strengths please leave knowing they aren't they only game in town.

AJAX/JSON and Web Services via SOAP are covered by Part 5 of the book. AJAX and JSON in PHP can also be it's own book given all the AJAX libraries out there. Kevin does a great job giving a quick overview of AJAX and talks a bit on how to use it with the Zend Framework. This will only wet your appetite on the subject but I felt it was a pretty good start. The following chapters focused exclusively on Web Services and SOAP. PHP5 has solid support for SOAP minus some interoperability issues and Kevin covers this well. As a shameless plug I'd also point anybody doing SOAP-based web services in PHP to check out the PHP SOAP Toolket (PST) which works around some of the interop issues. Additionally I'd also point you to this utility that gives you all the features of PST without having to install a thing. I digress...back to the book. One thing I feel that PHP is really good at is support for REST-based services which is largely ignored by this book. I think in a book like this you can only effectively cover one of either SOAP and REST, however, I would have liked to see REST at least mentioned and a quick comparison of when you might use one versus the other.

This book has also been reviewed by a number of other talented people so please feel free to factor their opinions in with mine to see if this is a book for you. I honestly do feel this book has a place on your bookshelf particularly for those just diving in more advanced PHP development.

PHP SOAP Toolkit

Tue, 03 Jun 2008 14:40:19 -0500

Michael Tutty, a friend and co-worker, gave the below talk at the DC PHP Conference . PHP SOAP Toolkit is a handy way to fill-in some of the "missing" pieces of SOAP support in PHP that make implementing both SOAP services and clients in a way that is inter-operable with other languages like .NET and Java. If you are interested in getting your feet wet with PHP and SOAP particularly with contract-first type of development you can take your WSDL on over here where you can quickly turn it into a downloadable PHP SOAP client that supports code completion.

View Full Size

DCPHP Slides

Mon, 02 Jun 2008 14:42:00 -0500

Thanks for all who showed up to my talk at the DC PHP Conference on "Fed Up of Framework Hype?". The slides are below and I'm sure some will ask about MVCnPHP which can be downloaded here. I know MVCnPHP isn't quite documented as much as I'd like...please ask questions OR wait as I will likely have a blog post about how to get started with it.

View Fullsize

Cutting Use of Zend_Log in Half

Fri, 30 May 2008 10:03:00 -0500

As part of the framework we use at work, we borrow what we feel are the best components out there and logging is a key part of that. Logging should be simple to setup, easy to use and should minimize work on the developer. After all, you are going to do a lot of logging, right? We use Zend_Log exclusively and while I like it when coupled with Zend_Registry you've always got the following two lines of code:

    // at the beginning of our application (in a singleton or in     // index.php at the very least)    $logger = new Zend_Log($writer);    $registry->set(?logger? , $logger);    // Every time you log you have these two lines.    $logger = Zend_Registry::get(?logger?);    $logger->log($errorMessage,1);

Not bad, not bad at all. In fact Zend_Registry is a handy little class. But why call Zend_Registry::get() explicitly over and over if you don't have to? I mean wouldn't it be nice if you could simply do:

MyLog::log('SomeMessage', Zend_Log::DEBUG);

That's right, let's log things statically and let all the magic happen behind the scenes. We'll do just that with a small bit of code and best of all you won't even need Zend_Registry (again, great class but why use it if you don't need it). How? Well you need to use something that acts like Zend_Registry but allows us to log messages statically. To do that we'll create a new class called MyLog and the first thing is the allow the application (or any plugins) to register their loggers (click read more):

public static function registerLogger($loggerName, $zendWriter = '',     $isDefault = false){    if (!isset(self::$instances[$loggerName])) {        self::$instances[$loggerName] = new Zend_Log($zendWriter);			    }		    // If we weren't told this is the default logger yet none exists then force it    if (!self::getDefaultLoggerName() AND !$isDefault) $isDefault = true;        if ($isDefault) {            if (isset(self::$defaultLogger)) {                throw new Exception('Default logger is already defined');            }            self::$defaultLogger = $loggerName;        }    }

The $loggerName is a logical name given to the logger you are registering. This must be unique. $zendWriter is one of the many Zend_Writer children you can use. Finally $isDefault indicates if the logger given will serve as the default logger. This will allow us to use shorter notation in our application. Ok, once you have this you can register all your loggers:

// You only ever do these onceMyLog::registerLogger('kernel', new Zend_Log_Writer_Stream(getOption('logFile')), true);MyLog::registerLogger('somePlugin', new Zend_Log_Writer_Stream(getOption('path_logs') .     'SomePlugin.log'));MyLog::registerLogger('propel', new Zend_Log_Writer_Stream(getOption('path_logs') .     'Propel.log'));

This then allow us to log a message with a single line with any of the following

// Log to the default 'kernel' logger with only an informational message. // Default log level is Zend_Log::INFOMyLog::log('Kernel starting up');// Log to plugin's logMyLog::log('Plugin failed to initialize', Zend_Log::ERR, 'somePlugin');

While the above is nice we can improve by providing simple pass through functions for each Zend_Log log level:

// Same log to the kernel from above but shorterMyLog::info('Kernel starting up');// Log to plugin log like above but shorterMyLog::err('Plugin failed to initialize', 'somePlugin');

If you like all this logging goodness you simply need to grab this file along with Zend_Log and you are on your way. Please note the requires at the beginning of the class I'm providing. It is using a method called getOption() which you will either need to implement or replace it with relative pathing. We do it this way because we've optimized our application to use APC which likes a) require instead of require_once and b) absolute paths over relative paths.

Government in the Web 2.0 World

Wed, 28 May 2008 16:35:00 -0500

In a rare moment when Twitter was up Ivo Jansch put me on to one of his recaps of php|tek and I was particularly interested in a presentation by Terry Chay. If you haven't heard Terry talk there are two things you will leave with:

Your quota for the f-bomb. I know it may sound unprofessional but he does manage to use it to draw attention to the things that really deserve it. Truth told, though, he does simply enjoy cussing.
A bunch of web programming goodness particularly around web development and PHP

In Ivo's recap one thing that stood out for me was his declaration that when developing an application it is important to consider Stability, Scalability, Speed and Security and handling them in that order. Those four S's aren't anything new to me but the assertion that they had to be in a specific order was and it is one I couldn't disagree with more (for the right reason's I promise). So why do I disagree?

In truth I only partially disagree. If your job is more one with an eye toward engineering the next great, viral application then he's absolutely right. Twitter is learning this the hard way, whereas Digg, Facebook, Yahoo! and others successfully figured this out. Then there is me, the government IT worker not focused on any one site, rather, building a large number of smaller sites. Now you could argue that states like California, Florida, Texas, etc have enough of a population base to justify the same Chay philosophy here but generally my experience is that for government the order really ought to be Stability, Security, Speed and Scalability. Why?

Stability - Let's face it, if the application isn't stable the other three S's don't matter. Using my own original Chayism a secure, fast and scalable piece of sh*t is nothing more than that. An over-engineered piece of sh*t. Terry and I seem to agree here.
Security - In government, securing the data of citizens and businesses is paramount. That's not to suggest it isn't for the more Web 2.0, virual, social networking type sites but nearly every government system I've touched has had a strong focus on security. It's not just the usual stuff like SQL injections, XSS and CSRF but also the notion of feature-based security. By that I mean we apply our MVC model to only expose certain features to the public internet. A common example of this is to limit administrative features for use on our Intranet. Other considerations that move the security issue up the priority chain in government include watchdog groups and media outlets that thrive on good government scandals and mishaps. In Terry's defense (not that he needs it) one of the arguments I could see him giving is that it's pretty trivial to secure a stable, scalable and fast application.
Speed - After stability and security Speed is next in line. Not to further stereotype a state with plenty already out there, Iowa's sheer population suggests that the need to massively scale an application is going to be a rare issue. Serving as many requests per second, however, does come in to play. A great example why this is so is the Iowa Sex Offender Registry. From time-to-time some high profile sex offender cases have been covered on various media outlets across the state and this can cause short periods of high volume traffic. Making the code run as fast as possible allows us to meet these rare spikes. If we were unable to do this reliably we'd then have to turn to our last S...Scalability
Scalability - Again, don't get me wrong, I can see where scalability has it's place and I have heard talks on both trivial and more complicated ways to achieve this whether it be database replication, sharding a database, implementing memcached, etc. In fact we even use a few of these techniques in our Java environment which is the only platform we current support to scale horizontally. To PHP's credit, for Iowa's needs it performs well enough out of the box we often avoid having to put much thought into scalability. The big gain here is we spend less time on engineering concerns and more time focusing on customer requirements and trying to commoditize software delivery.

All that said, there is a lot to learn from people like Terry as I don't doubt that some day an application will come across my IDE that will require me to rethink the order of Stability, Security, Speed and Scalability. One thing that can be learned is that no matter what application you are working on, the analysis process and resulting requirements had better make it clear what that order should be.

Join me at the 2008 DC PHP Conference

Tue, 29 Apr 2008 11:45:00 -0500

A couple of weeks ago the folks at the DC PHP Conference announced the speakers for the 2008 installment of the conference held at George Washington University and yours truly was selected as one of the speakers. We're talking PHP celebs like Chris Shiflett, Chris Jones, David Sklar, Cal Evans, Eli White, Keith Casey and Ben Ramsey as well as PHP companies like Zend, Digg, Oracle and Ning just to name a few.

Despite the fact the Internet continually provides us new ways to collapse the world and brush elbows with like-minded people I still get a bit perplexed that anybody finds it interesting when I talk about PHP (or anything for that matter). That aside, I do have a talk I'm giving called "Fed up of Framework Hype?". Sound familiar? For those of you that occasionally browse these pages you may recall a prior post on the subject. Given there was a bit of interest in that post I turned it into a talk for this conference. Click "read more" to see the full abstract of the talk and be sure to register for the conference which runs June 2-4! Abstract for: Fed up of Framework Hype

How good can any PHP framework be when it seems a new framework is dropping on the daily? It�s not just PHP�you�ve got Rails, Spring, Django and don�t waste your time Googlin� on the subject�there isn�t enough time in the day to read up on all that crap. Shame on us architects. Why? With all the talk about the baddest, new framework out there we never take the time to articulate their value (if any). So here it is, one guy's view on frameworks and the real value they have for you.

See, nobody wants to talk the fact that frameworks have a bunch of empty rhetoric around them. Their value is often discussed in terms of coolness and ease of use. If you are talking to a manager-type, balding, high strung, concerned about their budget you will quickly learn they could care less. They�re focused on the bottom line (where you should be focused).

This talk will focus on how to evaluate a framework and when not to use one. Yes, that�s right�I said it. You may not even need a framework! But should you need one we�ll talk about framework pre-requisites, why establishing goals for your framework is important, the key components of a good framework and how to help your organization get the most out of which ever framework you choose.

Don�t like frameworks? In this short talk it may be hard to convince you they can be good but I do know why many hardcore PHP-ers think they suck and we can talk about how to make a frameworks suck less, maybe even get you to like one.

Protection Against Cross Site Request Forgery (CSRF)

Fri, 25 Apr 2008 16:01:00 -0500

In working on the Geeklog 2 codebase, much of work forms the basis for stuff I do at work, I finally figured it was time to add handling for CSRF to the codebase in a way that forces it's use without the developer having to explicitly do anything. In my experience security has, sadly, become one of the last things on the mind of PHP developers (kudos to you numerous exceptions out there) so finding a way to help the developers protect their application from CSRF in a way that avoids them from having to explicitly consider and handle it themselves was key. However, to better illustrate my needs let's discuss a few high level requirements, shall we?

CSRF solution must apply to any and all forms in the system.
CSRF solution must work even in the case where the page served has multiple forms
CSRF solution must work for both GET and POST
CSRF solution must be applied to all forms without the developer having to make any explicit method calls to CSRF-related functions.

The solution? I've basically adapted what Chris Shifflet proposed in this blog entry from a few years ago. For the lazy, his solution involves including a token in each form and then putting the token value and the time the token was created into the user session. Upon submission of the form, the form value is then checked with the session value and then the time the token was used is compared to some sane time-to-live (TTL) value. Having this solution in mind I then added a few more details to the requirements above:

The security token must be autogenerated and inserted into each form
Each command (we operate in an MVC model) must have the ability to specify where it expects the token to be (e.g. POST or GET). The default value for this must be in the $_POST (in fact I question if using GET at all makes any sense).
The solution must not check for the token in the $_REQUEST
The solution must allow each command to set the TTL for the token.
Should no TTL be explicitly given, the system must use the default of 3 minutes

(click 'read more' for the solution) Ok, so armed with those requirements here is how the implementation went. Not unlike most MVC implementations we have a class representing a view (or a single page within the system). We have a few abstract classes in our codebase but the one of most importanc is BaseViewFlexy.php. The class in this page uses the Flexy template engine. In this class there is a compile() method that takes the given Flexy template and compiles it into PHP code. This is the point where we want to insert our security token and the best way to do this was to create our own Flexy compiler that does this work with the following method:

protected function injectSecurityToken($content){    $content = str_ireplace('</form>',        '<input type="hidden" name="glSecurityToken" /></form>',    	$content);    return $content;}

If you notice above I don't actually inject the value. Remember that we have bootstrapped the Flexy compile process so the above code ends up in the compiled Flexy template which, again, is PHP code. Now we need to insert the value for the token when we do our normal Flexy variable substitution. To do this our BaseViewFlexy.php file has a compile() method:

public function compile($templateToCompile){    // Compile the flexy template using our custom compiler    $this->flexyHandle->compile($templateToCompile);    $this->flexyElements = $this->flexyHandle->getElements();    	    	    // Use Flexy to inject token (if needed)    if (in_array('glSecurityToken',array_keys($this->flexyElements))) {    	$this->flexyElements['glSecurityToken']->setValue($this->getSecurityToken());    }    	}

You'll notice the call to getSecurityToken() above. That is the method where we generate the token, set the token and token creation time in the session:

protected function getSecurityToken(){    $token = md5(uniqid(rand(), TRUE));    $_SESSION['glSecurityToken'] = $token;    $_SESSION['glSecurityTokenTime'] = time();    return $token;}

Ok, so to this point we have insert the HTML hidden field that will hold the security token into our compiled Flexy template and we have set the appropriate value for the token and added the token and token creation time to the session. Because we did all this by overriding methods Flexy uses natively we have guaranteed this code will be executed for every form without the developer having to explicitly call anything. Now we need to do the checks upon submission of the form itself.

In our MVC implementation as with our View we have the notion of a command. Specifically we have an abstract class in BaseCommandUser.php that is aware of the user session already. All we need to do is add the security check for the token to it's constructor:

public function __construct($urlArgs = null){    $this->user = unserialize($_SESSION[getOption('user_session_var')]);		    if ($this->getUserRequired() AND ($this->user->getUserId() == 2)) {       // NOTE this makes use of the global forward feature in MVCnPHP       throw new Exception('doForward:login');    }    if (!$this->authorizedToRun()) {        throw new Exception('You do not have sufficient privileges to perform this action.            Please note that all attempts to illegally perform actions are logged');    }            // We may have data submitted to us.  Check the security token    $this->doSecurityTokenCheck();            parent::__construct($urlArgs);}

As you can see above we call doSecurityTokenCheck() which will throw an exception if it should fail. There are two reasons for failure 1) the token in the form doesn't match the one in the session and 2) the token has expired:

    protected function doSecurityTokenCheck($inputArray = self::INPUT_POST)    {    	    	if (!$this->doSecurityTokenChecks) return;    	    	$arrayToCheck = array();    	    	if ($inputArray == self::INPUT_POST) {    		$arrayToCheck = &$_POST;    	} else {    		if ($inputArray == self::INPUT_GET) {    			$arrayToCheck = &$_GET;    		}    	}    	    	// If we didn't get a token in the session before now set one        if (!isset($_SESSION['glSecurityToken'])) {			$_SESSION['glSecurityToken'] = md5(uniqid(rand(), TRUE));        }                if ($arrayToCheck['glSecurityToken'] == $_SESSION['glSecurityToken']) {        	// Valid token.  Validate age (if needed)        	$tokenAge = time() - $_SESSION['glSecurityTokenTime'];        	if (is_null($this->securityTokenTTL)) $this->setSecurityTokenTTL();        	if (!($tokenAge <= $this->securityTokenTTL)) {        		throw new Exception('The form you submitted has expired.  Please go back and try again');        	}        } else {        	Geeklog_Log::log('Cross site forgery request (CSFR) detected', Zend_Log::CRIT);        	throw new Exception('Cross site forgery request (CSFR) detected.  Please note all         		such attempts are logged.');        }        return;    }

As you can see from above you can set the class member doSecurityTokenChecks to avoid doing these checks at all (i.e. in the case of a view with no form fields). There is also a class member, securityTokenTTL, which can be set on a command-by-command basis. For sanity sake we default to 3 minutes.

That's it! I don't pretend this is perfect code but it does work and is in line with Chris Shiflett's approach which I liked. With a little bit of work we were able to build in protections against CSRF, which I don't claim to be 100% complete but do make such attacks considerably harder, and it is done in a way that secures all forms without the developer having to explicitly call anything. A true win-win in my opinion!

Google Summer of Code Opportunities

Tue, 18 Mar 2008 07:52:00 -0500

Once again this year, Geeklog was given a green light to participate in Google's Summer of Code Program (thanks again, Google!). That means it's time to encourage students to apply not only pick up valuable experience but to also be a part of a top notch team which brings experience and youthful excitement to open source development.

Dirk Haun, who leads the 1.x branch of the Geeklog Code base, has officially announced our participation here. For those of you interested in the 2.x branch (which I hope many of you are), I want to point out a few things about the status of the project as a glance on Geeklog.net won't give you the true impression of the work that's been done this past year.

Geeklog 2 is a ground-up effort that I've been spearheading to retool Geeklog by taking advantage of the OO features in PHP5 as well as build on our experience with open source content management systems. An out-of-date roadmap has been published and I plan to update that roadmap this week for any who may be interested. To help illustrate this we anticipate the first alpha release of 2.x during the next week or so. This alpha release, while clearly not code complete, will show all the moving parts of Geeklog 2 in action, we hope, will generate some much needed excitement in the Geeklog community. In line with that we hope this move will also motivate many of you students looking to participate in this year's Google Summer of Code to give a long, hard look at the Geeklog 2 ideas and apply.

More generally I had a great experience last year while on the Google campus and got a lot of really good ideas and I'd encourage any of you interested in participating to read my notes as they will give you ideas of the sorts of ideas we are tossing around. Obviously all open source projects live and die by their success in collaboration. That collaboration can even apply toward those of you considering applying to participate in our project there for I want to make it clear how I can be contacted:

IM: Yahoo (tony_bibbs), MSN (tony [@] tonybibbs [.] com)
IRC: irc.freenode.net in #geeklog (my nickname is IA-Outdoors)
Skype (tony_bibbs)

Please feel free to use any of the methods above to ask me questions about Geeklog or about the proposed Geeklog 2 projects.