Amarok Blog

Entries from Thursday, August 14. 2008

Thursday, August 14. 2008

GSoC weekly report - issue 11 Posted by William Viana Soares in liw at 17:44

Comments (0)
Trackbacks (0)

GSoC weekly report - issue 11

Here I am again, this time from aKademy 2008 in Belgium. It is my first akademy and as an experience it was awesome. The best part was meeting the people behind the nicknames. The community is great and it’s huge. Over 300 people came to the event, what is overwhelming. I’ve learnt many things, talked to many experienced people who really knows what they are talking about.

The organization of the event was perfect, there were many interesting talks, it’s a shame I’ve had to miss some of them. The social event sponsored by Nokia and the boat trip today were really really awesome (free beer, free food, what else could you ask?).

The only bad thing was that it was not really very productive in terms of code but it was really helpful to meet some of the plasma guys who were really kind to me and helped me a lot.

What was also very cool was the n810 that Nokia gave to some of us (a lot of us). It has become the favorite toy arround akademy. It would be really nice to have amarok playing on one of those with an adapted UI for the touch screen. Maybe someday, who knows ?

As for the Summer of Code program, well, it’s coming to an end and I still have lots of things to do, what is making me feel a little bit worried. I’ll have keep coding after deadline (18th august) to go as further as I can.

No snapshots this week, sorry

Thursday, August 14. 2008

GSoC weekly report ? issue 11 Posted by William Viana Soares in liw at 17:44

Comments (0)
Trackbacks (0)

GSoC weekly report ? issue 11

Thursday, August 14. 2008

Project Neon: neonmake Posted by Harald Sitter in apachelogger at 16:36

Comments (0)
Trackbacks (0)

Project Neon: neonmake

I totally forgot to blog yesterday :-S

Anyway, since the first day of Project Neon, there was neonmake. You might be wondering what neonmake is, though if you read all the other blog posts about Project Neon you probably know that I will explain it as following:

neonmake is a wrapper around make, ensuring all environment variables are set as necessary

That however doesn't really describe it very well, in theory neonmake should be called amarok-nightly-kde-nightly-cmake-make-sudo-make-install, which of course is far too long

Well, let's get through it step by step.

neonmake consists of 3 parts - neonmake, make.sh and varsrc

neonmake is a wrapper around cmake, make.sh and sudo make install
the nifty thing about it is that it will bring you to $src/build, or stay there, or create it (i.e. it forces you to do out-of-source builds and keep your source tree clean
it will also detect whether you are trying to compile anything amarokish (i.e. if amaork is part of the source directory's name) and tell make.sh about it

make.sh is a wrapper around make and varsrc
it will force compiling against kde-nightly or amarok-nightly depending on certain magic cases and invoke vasrc
once varsrc is finished it will run make

varsrc is responsible for the environment variables and is usually invoked by all amarok-nightly- or neon scripts

The actual capabilities are quite confusing (I think I don't even understand it completely, and I created that thing after all).

you can run neonmake with kde or amarok as argument forcing it to compile against kde-nightly or amarok-nightly
if the source folder contains the word "amarok" neonmake will asume you compile against amarok-nightly
neonmake will create and/or take you to a subdirecotry called "build" ensuring you do an out-of-source build
if 1. and 2. don't apply varsrc will check whether kde-nightly's kde4-config is available
if kde4-config doesn't return the proper direcotries it asumes we have kde-nightly installed but aren't using it -> variables for amarok-nightly
if 4. does not apply (i.e. no kde-nightly is installed) it will check for amarok-nightly's kde4-config, if it is available -> varaiables for amarok-nightly
if none applies it will throw out totally insane errors

to sum that up:

you can only compile against kde-nightly with kde as argument or when you are running it
you can only compile against amarok-nightly with amarok as argument or when kde-nightly is not installed or when the directory name contains amarok

Suggestions for improvements, as always, very welcome.

Now you go play with neonmake and I have to rest from this post.

Thursday, August 14. 2008

Responsible Disclosure, and Amarok ... Posted by Jeff Mitchell in jefferai at 13:55

Comments (18)
Trackbacks (0)

Responsible Disclosure, and Amarok 1.4.10

Yesterday we released Amarok 1.4.10, an unanticipated security release. From the Release Anouncement you may notice that we gave thanks to Google Alerts for notifying us of this vulnerability. This was perfectly accurate. Read on for why.

I want to say up front that the security value of this vulnerability rates so low that it's amazing Secunia even bothered with it. It requires local access (or at least, a shell prompt), and it requires our code parsing a file whose name was hardcoded to execute the code (doesn't)/overflow a buffer (doesn't)/do things incorrectly (doesn't). At worst, you could maybe make Amarok crash, and since this would be a race condition, you'd have to be extremely lucky, and this could only happen between when the user was downloading the Magnatune database and when it was being parsed. Not exactly mission-critical. So, the actual threat of the vulnerability was approximately nil. That wasn't the driving factor behind the sudden release -- the driving factor was the fact that since Secunia did issue an advisory, we wanted to respond to it as soon as possible. Which should have been 36 hours before. Here's where the bungling comes in.

At midnight Tuesday morning, Dwayne Litzenberger posts a bug report on the public Debian bug tracker with snippets of code from Amarok, and the following:

I'm not familiar enough with Qt to be sure, but it looks to me like the code creating a temporary file insecurely. At minimum, I think this code will break if another user has already created /tmp/album_info.xml (thus preventing the current user from deleting it).

Now, I'm more familiar with the KDE and Gentoo bug trackers, which explicitly ask you to not post security related information there, but to contact the projects directly (this would be in following responsible disclosure guidelines). Debian's bug tracker doesn't seem to say this, but it's hard to say -- in a couple minutes of looking around, I didn't see a link that would let me file a new bug directly. It seems you have to either email it in in a certain format or run their reportbug tool.

But as I was saying -- it gets posted to the public bugtracker, and Dwayne doesn't actually contact us directly. Neither does Debian. Perhaps they don't have bug triagers like I'm used to in Gentoo, and perhaps the maintainer of the package wasn't around for those 36 hours. Perhaps they simply didn't bother -- after all, we recently found out that Debian has created several patches for 1.4 over the years that their maintainer(s) never forwarded upstream.

Mid-Wednesday, Ian gets a Google Alert for Amarok -- Secunia has issued a security advisory against us. This is how we first find out about it, which was apparently considered enough of a vulnerability for Secunia to bother with it. Dwayne didn't notify us. Debian didn't notify us. Secunia didn't notify us. No one bothered.

This doesn't exactly correspond to normally followed responsible disclosure guidelines. A fellow developer thinks "Joe User" -- in this case Dwayne -- shouldn't be expected to know those guidelines. I don't buy it. If you know enough about security to recognize a vulnerability, you should know enough to properly disclose it.

My fellow developer also thinks that Dwayne acted responsibly, letting the world know about the vulnerability as soon as possible so that users could arm themselves against the problem until it was fixed. This is wrong, and easily seen to be wrong.

Let's forget for a moment that the vulnerability was miniscule in terms of threat level, and just think about it in terms of being a vulnerability, to prevent yourself from thinking "well yes, I see your point, but it was really miniscule" -- because that's not the problem with what happened here, and next time the vulnerability could turn out to be major.

Had Dwayne notified us first, instead of posting on the Debian bug tracker and letting it lie:

Our users would have been protected from the threat 34 hours earlier (it took us five minutes to patch it, and another hour or two to get the tarball out).
The information would have been made available to a wide audience via the Amarok users' mailing list and the packagers' mailing list 36 hours earlier, so that anyone worried about the threat would have been notified and could take action 36 hours earlier.
The Secunia Advisory could have come out already supplied with the information necessary for people to fix the problem (upgrade to 1.4.10).

By not following responsible disclosure guidelines, any users concerned about Amarok's security were unaware of, and running, unpatched software for at least a day and a half longer than if responsible disclosure guidelines had been followed. Far from letting the users know so that they could act to protect themselves, the users actually ended up being the ones getting screwed here.

Now, I will say something in Dwayne's defense, on the off chance that he could spot a security bug but really didn't know responsible disclosure guidelines -- on their bug tracker, Debian has the following piece of information:

Don't file bugs upstream: If you file a bug in Debian, don't send a copy to the upstream software maintainers yourself, as it is possible that the bug exists only in Debian. If necessary, the maintainer of the package will forward the bug upstream.

In this case, the first "if" in that sentence should have failed -- it shouldn't have been filed in Debian's bug tracker. But even if the user decided they want to put it there, security bugs shouldn't be included in this -- they should not initially be public, in following responsible disclosure guidelines; or, if Debian wants security bugs to go through its public bug tracker as well, they should be on the ball and not sit around on these reports for more than 36 hours.

So, to wrap up: disclose security bugs you find in a project properly. Contact the project, and if you must post it publicly somewhere before giving the project a reasonable chance to respond, don't sit on it, but contact the project as well and make sure they know about it so they can start fixing it. Do it right, and the one getting the credit for notifying the project won't be Google Alerts; it'll be you.
Continue reading "Responsible Disclosure, and Amarok 1.4.10"

« previous page (Page 1 of 1, totaling 4 entries) next page »
Frontpage