Automatic Script Updater

[Jakob Kummerow]

Thanks for all the feedback :-)

> If the attacker is able to manipulate files on the server he can, depending
on the implementation of the upgrade algorithm, put _older_ versions there.
With the correct signatures he got from back then. So an attacker could
possible bring older, vulnerable code back to the user.
So version information has to be signed, too, and checked to make sure the
version on the server is really newer than the installed one.

Oh, right, I hadn't thought of that... And even though I think that
it's rather unlikely for someone to do this, I completely agree that
the updater must be protected against that kind of scenario.

> Why this extra file with the version then? Just to create the final package?

In the vast majority of cases, there will be no newer version
available (since we don't intend to release daily/hourly updates on a
regular basis). So, to create as little traffic as possible, Amarok at
first only downloads the "version" file that is only a few bytes in
size (plus HTTP protocol overhead, of course), and then decides based
on the contents of that file whether to continue with the updating
process (i.e., whether to download the main archive and its
signature). The "version" file is only used for this check, and is not
stored permanently on the client side.
We can't use the script.spec file for this check because it is packed
inside the archive and thus not easily accessible over http.

I think there are two solutions which both solve the problem pointed
out by Sven:
(1) before installing the update, check whether the version string
specified in its script.spec equals the one from the "version" file
(2) Probably even easier to implement: include *both* main.tar.bz2 and
"version" into the signature.

I'll have a look at that second approach right now.

> For scripts shipped with Amarok this sounds like the best way.
> Thinking about it Jakobs scheme has the problem that old, vulnerable
> script files are still available system wide, they are just not being
> used as the ones installed by the user are being preferred. But the
> clean solution would be to fix the ones the system provides for all
> users at once.

Well, yeah, updating the system-wide scripts would be nice, but:
- if we let distributions do it via their package managers, we
completely rely on them. What if they take a week or more? What if
they have a policy to only deploy security updates? I agree with Mark
that this is not a good solution.
- if the updater should do it, it needs root access, meaning the user
has to be prompted for a password. Personally, I much prefer it if the
updater works silently and unnoticably in the background.
Also, I don't think that it's a problem to keep the version of the
script that was shipped with the respective Amarok version around.
Firstly, it won't get loaded unless a user wipes his
~/.kde4/share/apps/amarok/scripts dir and disables further automatic
updates; secondly, in any case it's not a regression compared to what
we have right now.

Cheers
Jakob