Automatic Script Updater

[Jakob Kummerow]

Hi,

it's time for me to publish my work on an automatic updater for
Amarok's scripts, and to invite all of you to comment on it and
discuss it thoroughly so that it can be included in 2.2.1. I'll try to
make this as short as possible without omitting important aspects, and
I'll use titles for the sections so that you can read this email
selectively if you want to.

What is this all about?

In the past months, we have seen that sometimes it would be very
useful if we could deploy an update for a script as quickly as
possible, especially without releasing a whole new Amarok version. The
lyricwiki script is the prevalent example for this; but the same
situation could occur for any script that makes use of external web
sites, since the web generally is a moving target.
The idea is therefore to implement an updating system for the scripts
(which is possible because they don't need to be compiled but can
simply be replaced). But since scripts are allowed to do almost
anything permission-wise, it must be made sure that the updating
mechanism cannot be abused to put malicious scripts onto users'
computers - not even if the Bad Guy who's attempting to do this has
gained access to the update server. In consequence, all updates have
to be protected by a digital signature.

Built-in vs. 3rd-party scripts.

The updater doesn't care where a script originally came from. It scans
all installed scripts and checks for each of them whether an update is
available. This check is implemented to be as lightweight as possible.
Updates are always installed to the user's directory
(~/.kde4/share/apps/amarok/scripts), because that's where Amarok can
write to without requiring root access.
The consensus on IRC so far seems to be that we initially only use the
system for updates for Amarok's built-in scripts, but it is always
possible to deploy updates for 3rd-party scripts as well, should that
be desired. As I said, the updater doesn't care.

Security.

An update is only applied if it has a valid digital signature. To
create such a signature, one needs to have the private key. The
private key is additionally protected by a password. The signature
algorithm used is RSA with a key length of 2048 bit.
This system is what is considered secure by the current state of
technology and science and is used widely wherever the integrity of
documents/files/whatever needs to be protected. You can ask security
experts for confirmation if you like; but as a CompSci student I'm
very confident that this statement is correct.
There are two cases that digital signing can't and won't protect against:
(1) If a cracker has already gained control over the update server and
placed a malicious update there, and then kidnaps and tortures one of
the developers who have the private key and know its password, then
depending on whether that poor dev manages to ingest his suicide pill
quickly enough, the cracker might be able to generate a valid
signature for his manipulated update.
(2) If an Amarok client is manipulated so that it no longer checks for
valid signatures, it will install any update it finds on the server.
But if a cracker already has that level of control over a user's
computer (the Amarok binaries are read-only for ordinary users after
all), be it because he knows the root password or by means of a virus
that manipulates running apps in memory, he could most probably just
install any malicious script he wants to all by himself, without ever
messing with our automatic updating system.

Necessary changes to Amarok.

Due to the signing stuff, QCA2 becomes a build time and run time dependency.
Scripts aren't loaded immediately any more; instead, for each script a
new thread is spawned that checks for updates and installs them if
applicable; finally the (possibly updated) scripts are loaded.
In utilities/updatesigner/, there's a nice little command-line utility
that can create signatures (if it can find the private key in the
current directory, and if the correct password is entered), verify
existing signatures, and create new key pairs if that's ever
necessary.

Workflow for releasing an update.

Whoever creates the update sends it to a developer who has access to
the private key. The developer (ideally) reviews the update, then
packs it into an archive called "main.tar.bz2", creates a signature
(in a file called "signature"), and a file called "version" that
contains the version of the updated script. These three files are then
put to <base-url>/<scriptname>/ (for instance
"amarok.kde.org/update/lyrics_lyricwiki/"). Done. Now, whenever an
Amarok client starts up, it will see the update and apply it.

"Wait, I don't want this. I hate automatic updates!"

Well, good for you, then, that there's a checkbox in the Script
Manager dialog that allows you to turn automatic updates off. But
don't complain about bugs in the lyrics script then!

Having a look at the code.

You can find my code either at
http://gitorious.org/~jmrk/amarok/jmrk-clone/commits/scriptupdater or
in the patch that is attached to this mail.
I am also attaching the private key that matches the public key that
is currently integrated into Amarok (i.e. in the patch). Note that I
would never do this with the private key that is supposed to be used
in the real world; this is just for you to play around with keys and
signatures. The password for this private key is "amarok" (without the
quotes). Very secure :-)
To fetch updates, for now I defined the URL of my personal webspace at
my university. Again, this is just for your testing pleasure. I
provide a dummy update for the lyrics script there that should get
installed (you can check it in the Script Manager, the dummy update
has version 0.3; or take a look at the file main.js, which contains a
big fat notice in the comment right at the beginning). I also provide
an update for the librivox service script that will not get installed
because its signature is invalid.
Feel free to play around with everything. The public key as well as
the update URL are defined in src/dialogs/ScriptUpdater.h (the key
*must have* those line breaks \n !). If you compile and install Amarok
with my patch, you'll have a binary called amarok-update-signer in
your PATH. Start it without parameters to get info about its usage.

Some more details about the implementation.

The versions of the currently installed scripts are read from their
respective script.spec files. Version strings are allowed to contain
dots and numbers, nothing else (i.e. "1", "1.1", "1.1.1.1.1.1.1.0" are
ok; "1.0b1", "1.0-1" are not). What's between two dots is interpreted
as an integer, i.e. "1.2" == "1.02" < "1.20" < "1.20.1" < "1.21".
Sections of the version string that aren't parsable like this are
interpreted as "0".
There are quite a few status messages that are printed to debug(), so
if you want to see what the updater does, be sure to start Amarok in
--debug mode and watch the output.

What remains to be done.

- Definitely: Define another URL for the updates. I propose
"http://amarok.kde.org/updates/" or something similar.
- Definitely: Create a new key pair, put the public key into
ScriptUpdater.h and store the private key carefully. Me, I don't need
to possess that key (or know its password), but if you want me to do
the job of signing updates, I can do it. Of course I'm not quite as
trustworthy as the long-time devs...
- Maybe: Change something else, depending on your feedback :-)

Apart from these changes, the code could be merged into master right
now, as far as I'm concerned. But I'm also prepared to change/improve
some details before that, just tell me where you think that
improvements are necessary.

That's it for now, I hope that I haven't forgotten anything (and that
I haven't bored you). Have fun with the updater, and I look forward to
hearing your thoughts.

Jakob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scriptupdater.patch
Type: application/octet-stream
Size: 38011 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20091008/626ffeb6/attachment-0002.dll 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: privkey.pem
Type: application/octet-stream
Size: 1833 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20091008/626ffeb6/attachment-0003.dll