Focus on Security

Geeklog: Focus on Security

Background

Those who have been around Geeklog long enough know the emphasis we put on security. Our roots began in security (Geeklog was created to run a security related website) and we were one of the first open source system in its class to feature a *nix-style permissions system. We believe our commitment to security is why our userbase has grown over the years and that is why we felt it is important to remind everyone in the GL community that the importance security plays has not changed.

To that end, we have created this page that will get you information related to Geeklog security. This will include updates on new security features, reports of possible exploits and security fixes. You all in the GL community make Geeklog what it is today and we always invite you to put an eye of scrutiny on the code we develop because we realize that even though security if front-of-mind for the developers, we still make mistakes.

Staying Informed on Security Releases

To stay informed about security issues, you can subscribe to Geeklog Announcement Mailing List where we will be announcing new Geeklog releases. Alternatively, you can also subscribe to the RSS Feed for the Security topic here on geeklog.net. And finally, there is also an option to check for new Geeklog releases built into Geeklog itself: Click on the "GL Version Test" link in the Admins block.

The Lifecycle of a Security Report

If you believe you have found a possible issue related to security here is the process the Geeklog team likes to follow:

1. Email geeklog-security AT lists DOT geeklog DOT net with a complete description of the issue. If you have an exploit, give the steps you took to reproduce the issue. If you have a fix please include that as well (all due credit will be given for your fix). Please note that this email is a distribution list. It goes to the entire Geeklog team.
2. Within 24 hours the Geeklog team will contact you to inform you we have received the report and have begun looking into it.
3. Within 3 days we will report back if we were able to reproduce the issues. If we could, odds are we will have a fix at that time as well. Please be patient as sometimes security reports for one specific scenario often lead us to identify other potential areas that could be affected by the same exploit. NOTE: if we can't reproduce your issue we will give you another chance to submit a working example of an exploit. If you can't get one to work we will be forced to dismiss this security issue and we would politely ask that you *not* report this to the various security mailing lists.
4. After confirming a security report we will prepare a security release. All Geeklog security releases include the last version with an srX tag. So, for example, if this is the first security release for Geeklog 10.2.1 then the security release will be named Geeklog 10.2.1sr1. If another security issue is found after that then the subsequent release would be Geeklog 10.2.1sr2 and so forth.
5. Once the security release is prepared we will release it to this site. At that time we will contact you, the reporter of the issue, and that time we encourage you to report this bug to the various security mailing lists.

A Comment on register_globals

For a long time, Geeklog required register_globals to be ON. As of Geeklog 1.4.0 (released in February 2006), this is no longer the case.

Security Releases

Please see our Security topic for details on past security releases.