drupal.org

Since I am among other things, a member of the Drupal security team, I sometimes get contacted about the security of particular modules or sites.

Today was such a day. A Drupal site developer had some suspicions about a contrib module being unsafe, since three of his clients' sites got "hacked". I asked about the symptoms and was told that a call to an advertising site got inserted into index.php.

This fact alone told me two things:

1) It is not Drupal specific; index.php is used by many PHP applications.

2) It is unlikely that Drupal was the attack vector used. Most systems do not allow the Apache user to modify PHP files.

A cursory look at the named module also didn't reveal anything particular unsafe.

I shared these observations with the concerned developer and I also suggested that somebody guessing the passwords or using a trojan might be responsible.

This isn't exactly news, but I was always assuming that Drupal people are a bit more honest and reliable. Turns out that I am pretty naïve.

As you know, we have these fancy download stats, thanks to a lot of people's work. On occassion, there are some troubles with them, and then Brandon looks at them in detail. Today, we blocked an IP which was requesting updates very often and with a lot of different keys. Either somebody's Drupal site is broken in a bad way, or somebody was trying to tweak the stats. We can't decide this based on the data we have, but if you find you don't get updates anymore, you probably should check your setup.

The real bummer was however, when Brandon started to specifically look for requests that were only out to game the stats for certain modules.

He found a module that reported several thousand sites using it, where almost all of the reports came from the same IP address.

So, you have been wondering what the overall effect of the git migration was on drupal.org's performance but didn't dare to ask?

Here's the answer: I don't really know.

The reason for this is that at the same time we made two other changes: all the CVS related URLs were temporarily disabled and the issue statistics pages for each project were restricted to logged in users.

The map on the home page of Drupal.org is one of the most-noticed new features. It started with the prototype, which was just that— a Flash-based idea for what might go there. During implementation, we had to figure out what exactly it would be and how it would work.

First, we needed to know where people were. Drupal.org has the advantage of an audience who is more-likely to be using modern browsers, and we don’t need everyone’s location. I decided we should use the new Geolocation API, but didn’t find any existing modules. I wrote a small HTML5 user geolocation module to add a share location option to your profile page. For privacy, it is opt-in and rounded to the nearest 0.1 longitude/latitude. Over 5,000 have shared their location, less than 1% of active Drupal.org users, but still looks impressive on a map:

Some of you may have noticed it, but most probably have not:

the old DrupalCon sites that are still running Drupal are not accessible at the moment, they are locked by a htaccess script.

This is an unfortunate development, but in the end I didn't have any choice but to do this.

The reason for this is quite simple: the sites are unmaintained. With the associated DrupalCon, the various webteams dispersed and software updates weren't done anymore.

This means that the sites are insecure. And since they run on the same webservers as the main drupal.org site and all subsites as well as current DrupalCon sites, I had to act.
I should have acted much earlier. It is unfortunate that this caused troubles for some people who linked to the sites. But you can't really expect such a temporary site to be around forever.

Now, you can think that I should maintain the sites myself. But quite frankly I don't have the time for this.

What should happen now?

The days before the Drupal 7 release were a scramble to organize a PR effort, including a new landing page and changes to the home page. Both are custom pages rendered by the drupalorg module, Drupal.org’s site-specific module. Site-specific modules need sites to work, and we were ready with infrastructure built during the Drupal.org redesign.
The days before the Drupal 7 release were a scramble to organize a PR effort, including a new landing page and changes to the home page. Both are custom pages rendered by the drupalorg module, Drupal.org’s site-specific module. Site-specific modules need sites to work, and we were ready with infrastructure built during the Drupal.org redesign.

The Drupal Association is constantly looking for ways to make Drupal.org more useful for the community. Currently we are working on a Drupal Marketplace which will allow Drupal Service providers to publish listings and categorize them.

The Drupal Association is constantly looking for ways to make Drupal.org more useful for the community. Currently we are working on a Drupal Marketplace which will allow Drupal Service providers to publish listings and categorize them.

With the Drupal.org redesign launched, I’ve heard many ask, “what’s next?” We always do regular, incremental improvements through the infrastructure and webmasters projects. This will continue, with the new design as a foundation and deployment workflow improved by the redesign project.

I've found some time to investigate some drupal.org server logs and found that while everything is generally working, there are some strange things happening.

Every full hour our access stats go up by almost 150%. I looked at the IPs that produce a lot of hits over the day, but they weren't responsible for these spikes. The spike is produced by a lot of different Drupal sites that request our update data when the hour strikes.

And why? Because we tell them to! In line 239 of our INSTALL.txt we instruct people who install Drupal to request our update stats at precisely that time. A classical facepalm.

Thanks to Varnish and the generally robust drupal.org infrastructure, this isn't an actual problem, but with the continued growth of the number of Drupal sites it might become one.