MetaBrainz Foundation Community Blog
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!
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.
bcrypt password hashes, with a cost parameter of 8, for all accounts as of March 25th 2013.
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.
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.
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.
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:
Finally, we would like to get some suggestions and feedback on where we should host our mailing lists. We’re considering:
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!
We have one aging machine (scooby) that has been in continuous service since 2006. Back then we didn’t have as many options for hosting source code, mailing lists and blogs. Today, we have a lot more choice and we’re opting to host fewer things so that we can focus our energy on hosting MusicBrainz and not a bunch of ancillary stuff. Our goal is to retire scooby soon and move the services that run on that server elsewhere.
Our blog is the first thing to move: We’re moving it to wordpress.com and we’re nearly done with the move. But, we dont have a decent wordpress MusicBrainz theme for our blog. If anyone is interested in taking an existing wordpress theme and making it a custom MusicBrainz theme, we would love your help!
If you’re interested, please leave a comment and we’ll get in touch with you to coordinate this process.
Thanks!
Digital West, our ISP, will be doing some router maintenance on December 30, at 12:01am Pacific Time. We may experience 1-2 minutes of loss of connectivity around that time.
For once, the problem will not be us. 🙂
MusicBrainz will be attending the Google Summer of Code mentor summit, and we’d love to have some stickers to hand out, so our fellow open-source friends can show off how cool we are. Sadly, we don’t have the skills to actually make the designs to send off to get printed… but that’s where you come in!
Do you do graphic design? Do you know someone who would be willing to help us? If so, please get in touch with us – leave a comment, tweet us or shoot an email to info@musicbrainz.org. Thanks!
We’ve just updated our search servers with a new release. This release adds support for a new improved json format for the search server and will be publicly available after the next mbserver release. We also now output the date (in the XML/json) the index was last updated so you know how old the results received are. This will be exposed to the end-user in the web search results in an upcoming release of musicbrainz-server.
Thanks to Paul Taylor and Aurélien Mino for making this release happen!
The maintenance we were doing is complete. You can safely resume editing now.
We have a minor hosting change to make (change how an instance of memcached is managed) that will lose all of the current release editor sessions. We will make this change tomorrow, Thursday at 20:00 UTC. During this time, any release editor session that is active will break and you will lose your changes in the release editor. To prevent this from impacting you, make sure to submit any changes before 20:00 UTC and wait for us to post another entry saying that the change is complete.
The rest of the site will be unaffected by this change.