Category Archives: General

Phew: MusicBrainz is unaffected by the Heartbleed fiasco

As you’ve probably heard all over the net, a vulnerability was found in a very popular and critical piece of software that a lot of sites on the net use. While we also use said piece of software, our version is a bit older and therefore we’re not affected by this bug. There is no need to change your password, unless you use a common password on any of these affected sites listed in the link above.

To get an idea of how serious this issue is, take a look at this stunning list of affected sites!

But, don’t take our word for it. Use this link to check to see if is affected.

Now go and change your passwords. NOW!

New editing feature: adding new entities from inline search fields

As mentioned in the blog post for the 2013-12-23 server release, a useful new feature for editors is the option to add new entities directly from inline search fields:


There’s an “Add a new [entity]” button at the bottom of (most) search result menus, which upon clicking will open up a dialog in the page. The dialog contains a form identical to the one you’re used to when creating entities the old-fashioned way — that is, from the Editing menu at the top of the website.

Once you’ve successfully added a new entity from the dialog, it’ll be automatically loaded into the search field you started from.

The visible exceptions to this feature are that you can’t add new areas (only location editors can add those), or releases (because those take a lot longer to add, and it wouldn’t be useful to do so in a small dialog that you can accidentally close), and finally, you can’t spawn an add-entity dialog within another add-entity dialog. :)

Another change that went along with this feature (that editors should be aware of) is that we now require artists and labels to be selected on the “Release Information” tab of the release editor.


Previously, you could enter plain text into these fields, proceed to the next tab without selecting a search result, and handle creation on the “Add Missing Entities” tab. Because “Add Missing Entities” has a very limited UI, in the future we’d like to remove it in favor of easier entity-creation on the other tabs. This is a small step towards that. Note that you can still use “Add Missing Entities” for track artists — this change only affects the release artist and release labels on the first tab.


Don’t hesitate to report any bugs or suggestions about this feature to our issue tracker:

All MusicBrainz sites downtime

On Sunday, December 29th at 1pm PST, (2pm AZ, 4pm EST, 9pm UK, 10pm CET) we’re going to swap out our network switch. During this time all MusicBrainz sites hosted in California will be unavailable. (that is all sites, save for the primary and secondary FTP mirrors and the FreeDB gateway).

The work will not start exactly at 1pm, but we’re doing to start executing our plan at 1pm. The exact time for the outage will be announced via Twitter and via the banner on

We hope that this outage will last only 10-15 minutes, but as these things typically go, you’ll never know how long it will really take.

Sorry for the inconvenience.

MusicBrainz Read Only Between 2PM – 3PM UTC

We need to do essential maintainance on the main MusicBrainz database server today (specifically upgrading to Ubuntu 12.04 LTS). We’re aiming to get this work completed within an hour, and will require MusicBrainz to be in read-only mode for the duration of the upgrade. We’re going to go read-only from 2PM UTC (6AM PST, 9AM EST, 3PM CEST) to begin this work.

Sorry for the inconvenience!


Venue and Studio Support: Introducing Places

MusicBrainz now supports venues and studios via our new “place” entity!

This was one of our Google Summer of Code projects for this year and many thanks to Nicolás Tamargo for his work on it. We released his work a few weeks ago and after a few initial hiccups, it’s looking good and we want to let you all know about it. :)

So what can we do with places?

The most obvious thing we can do now is store information about recording, mixing and mastering locations.

For example, the studios listed in the credits for Universe by Kyoko Fukada:


and the venue for the recordings on Live in Cartoon Motion by Mika:


We can of course link the place to a variety of external sites, as can be seen in the list of URLs for Wembley Arena:


Some places are made up of several parts. In those cases, we can link one place as being part of another. For example the various studios at Abbey Road Studios:


or the hall and theatre of the Barbican Centre:


We were already able to add engineers to the database as artists, now we can also say which studio they work at, as seen here for the studio Railroad Tracks:


Many orchestras and sometimes other artists have a home venue where they perform on a regular basis. These can now be linked, like in you can see for the Barbican Centre: Barbican Hall:


A premiere is sometimes held for a work and now we can link those works to where the premiere was held, e.g. the following works which were premiered at Carnegie Hall:


The place can also have coordinates, which make it possible to pinpoint the location on a map. The MusicBrainz website doesn’t show any maps at present, but here’s a map of all places with coordinates by Mineo:



No, we do not yet support events.

Thanks to nikki for writing this post.

We’re going to take the HTTPS plunge!

Yesterday in our dev meeting we agreed to take the HTTPS plunge for all of our web site traffic in as little as 2 weeks time. This means that all web site traffic (not the web service) will be served over HTTPS; if you visit any MusicBrainz HTTP URL (e.g. ) you will be redirected to the equivalent HTTPS URL (e.g. ). This will not be applied to our web services, you’ll still be able to access those with HTTP. However, we do encourage all of our web service users to make use of HTTPS when possible.

We have one bug to address before we make this switch. And if we can find a sufficient fix for this in time, we’re going to make the HTTPS switch on 16 September 2013. If we can’t find an acceptable fix, we’ll have to postpone this switchover.

If for some reason you can see that switching all web site traffic to HTTPS is a bad idea, please leave us a comment ASAP.

EU FTP mirror wanted

The OSU Open Source Lab hosts our FTP site in the US (thanks!!), but downloading from it from the EU is quite slow. We’re wondering if anyone would be interested in setting up an FTP mirror that is located in the EU? Sadly, we have no idea what sorts of bandwidth would be required for this, but we’re currently using less than 50GB of disk space.

If you’re interested, please leave a comment. Thanks!

Potential Security Leak

What Happened?

On March 29th 2013 we discovered that one of the MusicBrainz database dumps contained password hashes for a large portion of MusicBrainz accounts. While we don’t believe that these password hashes are either useful or widely distributed, we are requiring all users change their passwords.

What Data Was Leaked?

bcrypt password hashes, with a cost parameter of 8, for all accounts as of March 25th 2013.

Why Did This Happen?

We’ve recently began work on a long standing ticket against MusicBrainz server – MBS-357, “don’t store passwords in clear text”. We’re going to be moving away from clear text passwords, and we’ve decided to use one of the current industry standards for hashing passwords – bcrypt. Using bcrypt means that MusicBrainz will store only the hashes of passwords, which in laymans terms is a “fingerprint” of the password. Hashing means that we never store the actual password, but only the hash. There are many hashing functions available, and bcrypt is designed to be an expensive hash to compute with an adjustable “cost” – this makes it very hard to find out what the original password was via brute force attacks.

While this does mean that it’s hard to extract passwords from the hashes, the initial round of hashing passwords to move away from clear text is time consuming. As such, we built a small program that would gradually hash passwords over the course of a few days in order to make the switch from clear text passwords to secure password hashes done with as little downtime as possible.

This script hashed the password into the bcrypt_password column for all editors, and would also be notified when users changed their password in order to update the hash. Unfortunately, our database dump scripts sanitize this data by excluding data after-the-fact, rather than declaring what data to dump before running the script. As such, it dumped the entire editor table with the new column, as we forgot to add a rule to exclude this column.

Our Response

The database dumps that contain this data were promptly deleted, and have been replaced with correctly sanitized database dumps. Unfortunately logs from this server do show that this database dump was downloaded, and as we have no real indication of where this data now is, we’re treating this seriously. We have adjusted our database dumping scripts to be very specific about exactly which data they should export, so that in the future we will not leak private data by making the same mistake again.

We’re extremely sorry about this mistake, and while we don’t believe this data should allow attackers to retrieve user passwords, we can’t be 100% certain. As such, we require that all users change their password as soon as possible.

PUIDs are deprecated and will be removed on 15 October, 2013

tl;dr: On 15 october, we’re going to: drop table PUID;

In 2006 we added support for PUID acoustic fingerprints from MusicIP. MusicIP went out of business some years ago and the PUID service has been passed along, through various hands. Along the way it became neglected and the quality of the service went downhill. This spurred the creation of AcoustID which is our preferred solution for fingerprinting inside MusicBrainz today. We set out to let AcoustID support and PUID support live side-by-side in MusicBrainz for a while and we feel that almost enough time has passed. Therefore we’re going to remove PUID support from MusicBrainz in our autumn schema change release on 15 October, 2013.

If you depend on PUID support today, we encourage you to move over to AcoustID as soon as possible.

Housecleaning part 2: Moving our mailing lists

Part 2 in our housecleaning series concerns our mailing lists. Hosting mailing lists is quite a pain and we’d rather leave this pain to people who specializein mailing lists. So, we are proposing to do the following things:

  1. Remove the under-utilized list musicbrainz-italian.
  2. Remove the musicbrainz-commits mailing list. Github (and similar sites) have better notification systems, so we don’t really need this list anymore.
  3. Ask the Xiph Foundation to find a new home for the XSPF Playlist mailing list.
  4. Remove the under-utilized musicbrainz-users list since the forums are predominantly used for end-user discussion. We’ll point people to the forums for those.

Finally, we would like to get some suggestions and feedback on where we should host our mailing lists. We’re considering:

  • Nabble: This has gotten mixed reviews from various users.
  • Librelist: This site is quite new and UI reservations have been noted about it.
  • Savannah: This site has many more features than just mailing lists. We’re not certain if we can move only our mailing lists here.
  • Google Groups: We’ve heard complaints about spam and spam fighting tools. Has this improved recently?

If you have any comments on any of these solutions or proposed list consolidation ideas, please let us know. Also, if you know of a cheap/free/good list provider that we didn’t list, please let us know!