Something which passed me by completely was that this Monday saw the release of YaCy 1.0 (in German), but as you can see on Alessandro’s blog I might have been just about the only one who didn’t get that particular news item. Congratulations on making version 1.0 guys!

I was also toying with the idea the other day of making quarterly summaries as well. One blog post a week is great as it forces me to write, thus improving my writing, but it doesn’t really do anything for discerning trends, or changes in the way I work. This could be interesting

Finally, I should really start planning for writing my yearly “technology stack” post by diffing what I used back then and what I’m using now.

I am already certain that I’ve disappointed myself in some aspects, and surprised myself in others…

Yesterday I decided to attempt setting up a local Etherpad of my own, for use within the network/family. That meant upgrading my local server from Ubuntu Hardy to Karmic (well, I could’ve added the Karmic repositories to my installation, but a re-install was due anyway so…). I got Etherpad up and running locally (i.e. as long as I connect to it through elinks and 127.0.0.1:9000) but that doesn’t really help me as I want it available throughout the entire network. I will have to tinker more with that later.

There were, however, other services to get back online as well, such as WordPress. And it just so happens that while I was installing and tinkering with it, I happened to notice that there have appeared some rather cool (security-wise) plugins:

Antivirus

The antivirus plugin simply scans your current theme for malicious code, such as base64 encoded payloads, which apparently has been added to freely downloadable themes from various sites around the net.

I use the default theme, so I don’t really worry about the source for this theme but that just assures me that the theme is clean from the beginning. A security weakness could change that in a matter of seconds.

Invalidate logged out cookies

I don’t imagine I will get much use of this plugin as I normally only log on through my own computer, but should I find myself sitting in an internet café logging on, it is comforting to know that I won’t have to remember to physically destroy the auth-cookie which WordPress sets up on login.

Limit login attempts

This is a so called “speed bump”. This won’t create perfect security (there isn’t such a thing anyway) but it will slow an attacker down substantially, to the point where s/he gives up and goes after some other poor sap with more pathetic defenses.

It is a rather simple concept really: If the blog receives more than A erroneous login attempts in a row, ignore any further attempts from that IP for B minutes. If there are more than C * A attempts in a row, ignore any further attempts from that IP for D minutes/hours/days (where A, B, C and D are all fully configurable integers)

One time passwords

I will have to ask my webhost if they plan on upgrading to PHP5 any time soon, because this plugin requires it. What it does is to create a number of disposable (one time) passwords, which can be used instead of your regular password (which would be awesome to use for instance at an internet café, no risk that keyloggers or other eavesdroppers get hold of anything valuable).

Safer cookies

The original WordPress auth cookie implementation just checks that there is an authentication token in the cookie which correspond to an identical token in the database. Which opens up for man-in-the-middle attacks. Safer cookies adds your IP adress to the mix (well hash, I suppose) and thus makes it a bit harder for a session hijacking to take place.

Secure WordPress

I have to admit, this is my favorite of them all. It disables any information leakage at the login form (such as “sorry the password is incorrect”) An attacker, upon seeing that message immediately thinks “ah, so the username was correct”.

Furthermore, it removes the WordPress version from the html-source, which makes it harder for automated tools to know what attacks to apply.

(These are incidently the exact things I have been doing manually after every update, and hated every second of it since I don’t find mucking about in WordPress’ internals all that thrilling)

WordPress firewall

This one blocks a whole lot of badness which otherwise could be inserted through what the plugin calls “application parameters”. Examples of which are disallowing directory traversing (../../etc/passwd) and SQL queries.

The only thing left for me to do now is to continue to hack away at the Etherpad installation and wish you all a Merry Christmas

Update: Although good in theory, I all of the sudden started experiencing problems with the Invalidate logged out cookies plugin. The sort of problems which meant that I was being redirected to the login-page after a successful login… And since the plugin logs me out upon activation, I can only assume that there is some interference between that plugin and some other plugin. It is entirely possible that there is some configuration which could be done to get it all working, but since I get logged out on activation I can’t check that, and it isn’t all that important to me, I just chose to disable it instead. #HolidayLazinessFTW

And then I came along this post which got me thinking about what software I ended up using towards the end of my bachelors. Or the software I have learned of since, but wish I’d known about earlier. I began to write a comment to her post, but realized that it would be too long, so I write here instead. All credit to Hazel though, since without her post I wouldn’t have been inspired to write this one.

My list, as compared to Hazels, will not be as well-rounded, it won’t necessarily fit every student the way her list do. Also, the software I list will only be guaranteed to work in GNU/Linux, as that is what I used in the final semesters, and have continued to use since.

First of all, a text editor. It doesn’t really matter which, just evaluate a bunch until you find one you feel comfortable with. Once you have found “the one” become intimate with it. Become a frakking Jedi-master at wielding it. I’m still a padawan-level user of Vim, but I’m getting there.

I say the same about web browsers, mail clients and instant messaging clients. Find a good one, learn as much as you can about it, and use it effectively. Firefox, Thunderbird and Pidgin are my preferred tools.

A bug-tracker, although often web based creating a need for a web server, can often provide more “good stuff” than just tracking bugs. Stuff like statistics, or, if you think outside the box you’d be able to track things other than bugs, which I guess it was issue-trackers does. Some of these also include a wiki-system, which makes establishing a project-specific knowledge-base kindof easy. In the one university project where we used such a system (and where I realized its potential) we used Trac.

A blogging-system with an RSS-feed capable of being filtered on tags or categories could be used to distribute status updates to other members of a group. That I’m using WordPress should be fairly obvious to all.

Use a version control system wherever and whenever possible. With the next two suggestions on the list, “wherever” will be a lot more commonplace than one might first believe, even for non-programmers. At the university we had access to SVN-servers, and also tried Mercurial, a distributed vcs. Mercurial stuck with me ever since.

From generic suggestions, let’s go specific.

I could encourage you to check out markup languages such as reStructuredText or Markdown, to find one which suits you best and to run with it. And since I’ve now written the terms you’d need to Google, you could do that, but I’ll simply recommend LaTeX. The reason for markup languages in general, and LaTeX specifically is that you can then store your information in one plaintext format (which makes it easy to manage in version control) and can then transform it to a slew of other formats as needed.

Most of the time we needed to hand in PDFs. LaTeX excels in that and manages all the typesetting stuff and (obvious) formatting. Which leaves you with more time to focus on the content. One could also either extend LaTeX with Beamer, to create presentations, or simply generate a PDF and run Impress!ve.

For diagrams, graphs and flowcharts or representations of state-machines, Graphviz would be my recommended way to go. Again using plaintext to control the content, again with the benefits of version control. Inkscape saves files in the SVG format (again, plaintext) which might be usable (especially since it can also save files as both PS and PDF)

If you need graphical representations of statistical data or other plots, matplotlib could be the way to go.

I personally don’t like managing things, or management-related stuff, but lately I have been haunted by the feeling that if I used management tools, even if I would only be managing myself and my pet projects, I could be more organized and efficient. So I have started looking at TaskJuggler. It is similar to Microsoft Project, with the largest difference being that… you guessed it, you code the project plan ;D. Plaintext yet again. And then you compile the plan and TaskJuggler attempts to verify that no resources have been double-booked.

Considering each piece in this list on their own, it might seem like a waste of time to exchange one software with another. I do find each of these softwares impressive in and on their own, but it is when they are put together, when all their strengths are combined, that you tend to get the most out of it.

The all plaintext approach I have tried, both in groupwork at the university, and later on my own, work rather well. That so many of the softwares on the list can be used to communicate and transfer information between parties is also intentional as without communication the chance of a successful project outcome diminish rapidly.

The last (bonus?) item on the list would be to recommend learning, at least superficially, a programming language which you could hack together small scripts with. Something which you could use to “glue” together the other parts. I adore Python, and many of the softwares listed above have python-bindings ready to use. Perl, Ruby and others, which elude me right now, would undoubtedly work equally well or better, but as with the text editor, pick a language you feel comfortable with, and rock on.

I spent most of the night finishing up some work I was doing to help a friend, and finally got some time over to recoup and start addressing things in my backlog (primarily writing a blog post about a recent late night coding excursion). That plan was immediately sidetracked by the fact that WordPress 2.7.1 was released (and, for some reason the WP Automatic Upgrade plugin failed to upgrade) so I had to manually upgrade the blag. I also realized that I suck at documentation which left me almost dumbfounded as to what modifications I have made. Which meant spending some time with a local copy of the 2.7.0 install and the new release, and getting intimate with diff. This time around it is documented.

It seems that one of my modifications (aimed at separating the pingbacks from regular comments) are now an integral part of WordPress (or, if this is not the case, I suck at reading code).

I was unsuccessful in finding a way to bring back another modification however; in the previous version I had managed to get comments written by the post-author to be treated with a different style, making it stand out from the other comments. This is no longer the case. Will have to investigate this further.

One really nice outcome of this little detour is that I now know how to jump between lines in gVim.

Of course, not two seconds after publishing my previous post, while talking about it with a friend, he realized that it is not only the WordPress log-in form which has clear security implications (as in providing which of the two login-data was erroneous), but that WordPress could potentially leak information through the lost password retrieval / reset feature.

Don’t get me wrong, I love WordPress, but I am beginning to suspect that the immense popularity it has attracted, is due to its ease of use, and usability have never been known to often go hand in hand with security. And indeed, WordPress, with all the security “flaws” one can find in it, seem to have chosen ease of use over security.

It was, however, rather easy to fix this too, although it meant diving head first into some PHP code. The affected lines of code which we wish to disable is inside a switch-statement far down in wp-login.php.

Not everyone can use this approach of course, since your blog might wish to let users retrieve their password, or to register, or whatever, but for this blog, with me as the sole author, it works quite nicely.

I subscribe to Smashing Magazine, and just finished reading this article. Most of their articles does not appeal to me (mostly because I have no Photoshop skills, and don’t work with Photoshop at all) but there is the odd piece of gold there even for me.

Today it was in the form of summarizing things you can do to harden your WordPress installation. Sometimes though, funny little discrepancies sneak through. Like for instance, if you follow tip #8 (Suppress error feedback on the log-in page) your installation won’t leak whether it was the username or password which was erroneous. It does however leave an ugly red field (in which said error feedback used to live).

These types of solutions usually come with a real drawback, namely that if you try to access an account too many times, the account is locked and unuseable. Which allows for a malicious person to deny the author access to the blog.

I just tested this plugin, which seems to base the restriction on IP-adress instead of actually locking the account. While this makes it possible for an attacker to simply switch IP and continue the attack, the purpose of this kind of security measure is of course not to make an attack impossible, just infeasible, in the same way that a speed bump doesn’t make it impossible to drive down a street at high speed, but it can make it really uncomfortable.

I found myself today with the urge to finally, once and for all, find out what this “nofollow” business is. I have tried before, but either never understood it, or understood it only to discard the information. My understanding now is that the “nofollow” attribute tells search-engine crawlers whether or not I endorse the site to which I am linking. That is, if I have found a site which has helped me, and I want to give “love” back to the site, I then write a post, linking to it, NOT including the “nofollow” attribute.

The reasons why a blog might want to deal with this concept is simple: If you have a blog which has become somewhat of an authority in a specific topic, and you get a whole lot of comments, what is to hinder unscrupulous commentators from adding their own links to comments, which will then be indexed by search engine crawlers (they only see the html-source, where a link is a link, unless you mark-up specific links differently so that they stand out. That’s what “nofollow” is for.

However, when I was done reading (I searched Google, opened up a lot of tabs), I found “related links” at the bottom of one page (oh what a scourge on my time they are ;)) which lead me to another topic, “9 Easy Ways to Get More Blog Comments“, which offers up a slew of plugins which might make a difference.

One of these being the “Show Top Commentators” plugin, which purportedly gives “love” to the most active commentators of the blog. It’s a great idea but I’m just not so sure about giving the most active commentators the most love, since the quality of the comments should come into play as well. Of course, then you’d need a rating system, and a policy of who gets to rate comments, and soon it would be chaos. Having only the author rate comments could create a biased environment, running the risk that only positive comments would be rewarded. On the other hand, letting users rate each others comments… well let’s just say that it could work if only registered users were allowed to rate comments (although not their own). The sad truth is that a small portion of the unregistered commentators could not be relied upon to be honest, and would thus skew the statistics, knowing that, as they are unregistered, there is no effective means of tracking them and hindering their attempts at self-aggrandizing or sabotaging other user’s comments. I am however unaware of any such plugin which would work on ratings rather than volume.

Another (potentially) cool plugin, is WP-PostRatings which would give registered users, and possibly anonymous guests as well, the ability to rate blog posts. As with the “Top Commentator” plugin, this could be misused, this time by rivaling authors in the same niche. But that may just be the pessimistic side of me talking

In any case, there are a lot of nifty plugins for WordPress, although this one plugin seem engineered more towards generating quantities of comments rather than quality comments. And that would possibly be a better metric and a better merit for commentators.

First of all, WordPress 2.7… although the exterior isn’t any more exciting than you make it (themes), the dashboard… what can I say? I am having some real trouble seeing how anything could be done in order to make the dashboard better than it already is. WP 2.5 had a dashboard which worked. When WP 2.6 was released I believe my exact thought was “meh”. On a scale from 1-10 the WP 2.7 dashboard is as close to a 10 as it can be. Is it a 10? Quite possibly. Could another, better, dashboard come along at a later version, possible, but those devs would have to work their brains and asses of them to top this one. GOOD JOB!

One thing, however, which I think should be more “configurable”, is the amount of “meta-information” which WordPress emits. Things like the version number of WordPress, or the Windows Live Writer thingy. I set out earlier… “tonight” to find out how to disable the version reporting (after having executed some rudimentary grep commands trying to find where it was being enabled), and what I came up with was a couple of note-worthy things:

There is no real need to disable the version reporting, since the latest up to date version should, theoretically, be “immune” to all attacks on previous versions, and if you are running a previous version you should update anyway.

I of course, would rather go for the belt and braces type of strategy and as long as removing the version reporting isn’t hurting me, why should I keep it in there?

Also, I don’t know how I managed it while running version 2.6, but somewhere in that time the WP devs switched over from using straightforward function-calls in the code, to registering callbacks, and this might explain why my searches came up empty. Well, technically I ought to have found something, but never mind. It finally led me to Peter Coles blog which outlined what is needed to be done (and also enlightened me about RSD and Windows Live Writer). All in all, good stuff.

The one thing which made me a bit dumbfounded, although had I just blindly followed the instructions in the blog and read the information it should have obvious, was where to insert these snippets of code. My first attempt to implement it was directed at creating a plugin so that I wouldn’t need to hack (and of course forget about it) the correct file once a new version is released. That didn’t pan out well.

So, then I tried the instructions, entering the code snippets into functions.php. Well, first I searched for “functions.php”, and according to the link in Peter Coles post, it should exist in the theme directory. I have set up another WordPress installation on an “undisclosed location” and that installation uses another theme. That theme did not have a functions.php, which had me a bit confused, until I just decided to try creating the file, and putting the code snippets into it. Worked like a charm.

So, long story short, go to

[wp-install-dir]/wp-content/themes/[your_theme]/

Locate the file functions.php (or create it if there isn’t one), and insert into it the following:

For this blog, functions.php already existed, with a whole lot of code in it already, so I put these calls just below if the first if-statement, tried updating the front page and whaddya know? Success!

Update:

I just checked the rss feed (silly of me, to say the least, not to check it before posting) and what do I find? A generator tag with a url exposing the WordPress version. So, ok, you don’t necessarily need to kill off the generator tag, and I am quite unsure what the RSS/Atom specifications say about a generator tag, maybe they require it…, anyway, if you do want to remove the generator tag:

Go to:

[wp-install-dir]/wp-includes/

For every file having a name beginning with “feed-“, remove the line which begins with:

<?php the_generator(

The values inside the parens will differ, but there will be only one such line per file.

Finally, for some reason, on my other blog, this wouldn’t do it either (although it should have), so I issued another grep command, which lead me to default-filters.php. In it, the line

add_action('wp_head', 'wp_generator');

can be found, killing off this line finally solved it for me, although I didn’t need to it on this blog though… strange…

This won’t be a ground-breaking or revealing post of any sort, but as I just stumbled upon a page where the author had done an “autopsy” on an infected WordPress blog, concluding that the tools available to infect a blog are so simple to use nowadays that one would really have to pay attention.

The tools, he continued, automatically look for WordPress installations of a specific, vulnerable, version, and the, again automatically, apply one attack or another, to infect the installation.

Which reminded me that I really should remove the version string from that meta tag in the source code. I actually have a somewhat hard time understanding why it is put there in the first place. My browser experience, as a user is not diminished by the removal of said version string. Maybe I am missing something, but if I am not, the only purpose that string has, is to let users know (the ones who browse the source) which version of WordPress that is currently installed. (And of course, making those automated scripts find vulnerable versions easier)

Naturally, the safest bet is always to keep the installation up to date with the newest version always installed, but even so, why print the version number?

So, down to the nitty gritty. In your wordpress directory, there will be a directory called wp-includes, in which, among other files, you will find general-template.php. At the end of that file, there is a function which output the version string in a couple of different formats, xhtml, rss etc.

You will want to modify each of these strings, so that none of them can be used to reveal the version.