On November 22nd, I discovered two vulnerabilities in sites based on Drupal Core 7.9 with default configuration.  These were:

• an automatic remote phishing vulnerability (automated email sent from drupal user’s website can contain links to an attacker’s site!)
  Suggested CVSS v2.0: AV:N/AC:M/Au:N/C:P/I:P/A:N/E:POC/RL:U/RC:C (What’s that?)
  Suggested Drupal Security Risk Level: Moderately Critical (3 of 5)
• a potential XSS vulnerability (High Access Complexity… attacker must have MITM or control of a Proxy)
  Suggested CVSS v2.0: AV:A/AC:H/Au:N/C:P/I:P/A:N/E:POC/RL:U/RC:C
  Suggested Drupal Security Risk Level: Less Critical (2 of 5)

The technical details of this vulnerability have been removed until further notice from the Drupal security team

I decided to write a simple web spider in order to learn Python, and to generate a list of urls for webserver benchmarking & stress testing… and so Spyder was born.

Github:

https://github.com/trinitronx/Spyder

Spyder:

a simple web spider written in Python

When called on a url, it will spider the pages and any links found up to the depth specified.
After it's done, it will print a list of resources that it found.
Currently, the resources it tries to find are:

images   -  any images found on the page (ie: <img src="THIS"/>)
styles   -  any external stylesheets found on the page.  CSS included via '@import' is currently only supported if within a style tag!
(ie: <link rel="stylesheet" src="THIS"/>  OR <style>@import url('THIS');</style> )
scripts  -  any external scripts found in the page (ie: <script src="THIS"> )
links    -  any urls found on the page.  'Fragments' are discarded. (ie: <a href="THIS#this-is-a-fragment"> )
emails   -  any email addresses found on the page (ie: <a href="mailto:THIS"> )

An example script for doing something like this, 'www-benchmark.py', is included. It uses apache benchmark as an example.
Eventually I'll be experimenting with 'siege' for benchmarking & server stress-testing.

NOTE: Currently the spider can throw exceptions in certain cases (mainly character encoding stuff, but there are probably other bugs too)
Getting *working* character encoding detection is a goal, and is sorta-working... ish? Help in this area would be appreciated!
Filtering the results by domain is almost working too

Recently, I’ve received a couple requests to use some of my Photoshop artwork for various purposes.  Up to this point, I’ve released all of my large pieces of art under a Creative Commons Attribution Share-Alike 3.0 Unported license.  This means you can feel free to use them and create new works based upon them as long as you give me credit somehow.  Feel free to contact me, however, because I’d love to know that other people are using it ^_^

So, as long as you mention that I’m the creator of this work somehow, then it’s all good

In case it’s not clear, the creative commons site makes this a little less confusing.  Just click on the following image:

I finally got my home development server completely updated, including a freshly compiled Gentoo hardened kernel!  Now that I’ve got my server setup and working smoothly again, I started looking into the IDE side of the equation so I could do PHP web development on my laptop.

So after looking around a bit, I stumbled upon the idea of using Eclipse to do PHP development.  In the past I have disliked Eclipse due to it’s tendency to have problems with it’s workspace “.metadata” files over time, along with it’s slowdowns and/or freezing.  However, after seeing a presentation about Mylyn I reconsidered.  After looking up some other plugins, I was convinced that Eclipse is definitely worthy of a second look.  What’s Mylyn you ask?  In a nutshell: Mylyn is a task oriented plugin to Eclipse, giving you the benefit of saving what files & tabs you have open in Eclipse for a specific task.  A task can be anything, a bug report in Bugzilla that you’re working on, or simply a powerpoint presentation (An example given in the presentation with Tasktop Pro, the fully featured task oriented desktop app from Tasktop Technologies).

Why am I reconsidering Eclipse?  Well for starters:

1. It’s built on Java, so I won’t be tied to using Windows for my laptop forever (Eventually I’m looking into getting a Mac)
2. Mylyn allows integration with Bugzilla, along with a solution to my constant “too many tasks with too many tabs” problem.
3. It includes built-in task scheduling features, perfect to start training myself to do better time management.
4. Allows for developers to share “contexts” for each task (or bug) with one another, allowing for easy views on what parts of the code a bug/feature affects.  Collaboration is made that much easier!
5. The PHP Development Tools (PDT) project gives PHP code completion, PHP debugging (once you install an apache server library), and all the other nice standard features of Eclipse.  For the Apache module, you’ve got the choice of either the free & open source XDebug or the binary blob Zend Debugger.
6. The Subclipse plugin allows for nice integration with SVN (although I prefer git, I am forced to use for a couple projects).  I was also familiar with using this plugin in my college’s Software Development class, where we used Eclipse & SVN to do Agile Java programming with many different teams over the course.
7. The Ajax Tools Framework (ATF) gives many of the features that the FireBug plugin for Firefox supports including: DOM Inspector, JavaScript Debugging, live CSS style editor, and all that good stuff.  It does this by embedding Mozilla into Eclipse!

I’m really excited to start debugging PHP code on the server.  Previously I’d been using jEdit, an SSH terminal, and Firefox to develop.  This upgrade should improve my productivity a lot.

On Friday & had a quite eventful day involving a bunch of lucky and happy coincidences, along with an amazing spurt of ultra-productivity!  Although it was an interesting day, that’s not what this post is about.

At one point, I was working on creating a CUE sheet for episode 004 and realized that GoldWave was clobbering all the PERFORMER attributes for every track in the original CUE sheet I imported!  That was definitely no good, and really irritated me at the time.

My current workflow for CUE-ing a mix is as follows:

1. Export tracks from Traktor to a directory (ie: “~/Music/LyraPhase/004″), then make sure tracks are in order & named in the format: 01 – Artist – Trackname.mp3
2. Make a tracklist text file:
   ~/Music/LyraPhase/004$ ls -l --color=never > LyraPhase_004.txt
3. Run my magical script to generate a CUE file with empty INDEX points:
   ~/Music/LyraPhase/004$ tracklist2cue.pl LyraPhase_004.txt
NOTE: all tracks have initial cutpoints of 00:00:00
Opening tracklist file: LyraPhase_004.txt
Writing cue file to: ./LyraPhase_004.cue
4. Import the blank CUE file into GoldWave, listen, do audio processing stuff, then edit the track INDEX points.
5. Save the wav & CUE files.
6. Find out some extra stuff is gone after GoldWave got through with it

Enter perl:

So since I really like GoldWave otherwise, I decided to go dust off my monk robes & dive into perl again.  The initial goal was to be able to read in the 2 CUE sheets, copy INDEX points from one to the other, and then save it again.  I also have been thinking about other things in the future I may want to do with CUE sheets, so I decided to try to find some perl code to do what I wanted.

After a search, I found a module on CPAN called Audio::Cuefile::Parser which really didn’t do everything I wanted, or fully support the entire CUE file specification as per the documentation here.

After 1.5 days worth of hacking at it, I’ve successfully got 1/2 of the problem solved.  So far my Audio::Cuefile::ParserPlus module will happily read in CUE sheets and print out the track information for you.  The next step is to make a file output method, which should be simple now that the hard part of parsing in things via regex is finished ^_^

Current code snapshot can be found at my GitHub Repository
Happy Hacking  ^_^

- DJ Phasic

Thanks to the local dev server setup I have, along with svn and git, I’ve successfully and painlessly updated to wordpress 2.8.5.  Pushing changes to the wordpress_base branch on my site is quite simple, as I don’t really plan on modifying the core wordpress code that much.  Any changes to the code made by an svn update will only change files that I probably haven’t ever touched, so merging branches should be painless.  Plus, the core wordpress code is tracked by svn, while both the core code and my changes are tracked by git.  That way, I’ve got my own local branches that incorporate any updates made by svn, plus everything else.

In case you’re really interested and wondering how this is all done, see the following links:

http://codex.wordpress.org/Installing/Updating_WordPress_with_Subversion#Tracking_Stable_Versions

http://blog.zobie.com/2008/12/managing-wordpress-updates-with-git/

Basically all you have to do is follow the wordpress update instructions from the 2nd link, but replace the svn switch command with the one found at the 1st link.  The way to update in git is pretty smart, since all core wordpress code changes are tracked in the main wordpress_base branch, then updated via svn, put the changes into a new integration branch, then rebase the master branch onto that one & checkout the merged changes to the master branch.

Originally it seemed stupid to use svn to track the remote wordpress repo, however I tried using git’s svn capabilities and found that the only supported way to switch svn tags within git broke everything, so it’s actually better and more painless to use both CVS systems.