Automatic Update System for Scripts

Tue Sep 8 10:49:13 UTC 2009

Hey Jakob. Thanks for the effort!

I was thinking of making GHNS support versioning instead of proposing two
different ways for script updating.

the signature stuff is good, and the version info can be provided in the
script.spec file.

There is incomplete code for version check already in scriptManager.cpp. All
we need is to update GHNS, and most hard thing: to inform the script
writers.

I like the idea of making all default script accessable without root access.

On Mon, Sep 7, 2009 at 8:37 PM, Jakob Kummerow <
jakob.kummerow at googlemail.com> wrote:

>
> B. What works:
>
>   * generating key pairs (small command-line app)
>   * creating signatures for files (same small command-line app, the
> two can easily be split if deemed appropriate)
>   * copying all scripts from /usr/share/apps/amarok/scripts/ to
> ~/.kde(4)/share/apps/amarok/scripts/, which is of course necessary to
> make the scripts replacable without requiring root access
>   * determining the version number of the existing scripts
>   * checking a predefined location for updates
>   * deciding on the applicability of those updates
>   * downloading the updates
>   * verifying the signatures of the updates
>   * installing the updates (if verification was successful)
>
> That's pretty much all we need :-)
>

>
> C. What remains to be done is integrating all of that into Amarok, and
> here I need some help:
>
>   * At which point exactly is it most reasonable to perform the
> updating procedure? My guess is
> dialogs/ScriptManager::ScriptManager(QWidget* parent), or the
> beginning of dialogs/ScriptManager::findScripts(), but I'm not sure
> whether there's a better solution.
>   * With the changes incorporated, Amarok will need Crypto++ both
> for compiling and at run time. Crypto++ is available via the package
> managers of Gentoo and Ubuntu; I didn't check other distros but they
> should have it, too. How does one have to change the build system to
> integrate the new dependency? (In the simple Makefile I've used for
> testing, the required parameter is "-lcryptopp")
>   * The (probably) biggest remaining change is that so far, I
> execute the downloads of version, update and signature synchronously;
> I guess that will have to be changed to asynchronous operation.
> Unfortunately, I have no idea how the Qt event system that's required
> for this works. All I can say is "SLOT? wtf?".
>     Please, could someone either explain to me how I can use
> asynchronous downloads, or (even better :P ) offer to take over
> implementation of that part?
>     There's one small catch: The contents of the method
> ScriptManager::findScripts() should only be executed after the
> updating process, asynchronous or not, has finished. Otherwise an
> additional restart of Amarok would be necessary in order for the
> updated scripts to be used.
>   * Which base URL should be used for the update checks?
> amarok.kde.org/updates/scripts/ ?
>   * The public key that must be integrated into Amarok is around 400
> bytes of base64 encoded data. Should I put it as a string directly
> into the source code, or is it better to have it as a separate file?
> If the latter, where? I don't think there's a reason not to put it
> into the source, because we don't intend to change it; and if we do
> want to change it, that can happen in the next Amarok version.
>
>
>
> D. And here is the (planned) workflow for releasing an update:
>
> 1. Joe User in a spate of industriousness creates an updated version
> of greatscript/main.js and greatscript/logo.png
> 2. He sends them to Dev E. Loper for review.
> 3. Dev verifies that the new version works and doesn't contain malicious
> code.
> 4. Dev especially makes sure that in the first line of main.js, the
> NUMBER in "AmarokScriptVersion=NUMBER" got incremented. (It doesn't
> really matter by how much, but there must be an increment to prevent
> endless updating loops. Only integers are allowed, no point releases.)
> Dev memorizes the new version number.
> 5. Dev puts the updated files into an archive called main.tar.gz
> (important: without any enclosing folder!)
> 6. Using his private key, Dev signs the archive, generating
> main.tar.gz.signature.
> 7. Assuming the base URL for updates is
> http://amarok.kde.org/updates/scripts/, Dev now puts the files online:
>
>   mv main.tar.gz
> http://amarok.kde.org/updates/scripts/greatscript/main.tar.gz
>   mv main.tar.gz.signature
> http://amarok.kde.org/updates/scripts/greatscript/signature (note the
> renaming!)
>
> And yes, I know that you can't use mv exactly like that. But you
> understand what I mean, right?
> 8. Finally, Dev tells Amarok clients all over the world that an update
> is available, using the version number he remembers:
>
>   echo "<version number>" >
> http://amarok.kde.org/updates/scripts/greatscript/version
>
> 9. After that, when somewhere on the internet an Amarok is started, it
> will notice the update, download, verify and install it.
> 10. Dev and Joe pat each other on the back for having cooperated so
> well, dancing around the room because Amarok is ro'king so much :-)
>
>
> E. A few remarks:
>
>   * The filenames "main.tar.gz", "signature" and "version" are
> hard-coded into the updater, so it's important that the files are
> named exactly like that.
>   * Each script must have a "main.js" anyway, and a new requirement
> is that in the first line of that file, "AmarokScriptVersion=NUMBER"
> must be present. Whitespace and other comments are allowed as well.
> The line might for instance look like this:
>
>         // info for the update system: AmarokScriptVersion = 3   Do
> not change this unless you know what you're doing!
>
>     Updating clients compare the number in the first line of the
> existing file $KDEHOME/share/apps/amarok/scripts/greatscript/main.js
> with the contents of
> http://amarok.kde.org/updates/scripts/greatscript/version when they
> decide whether to perform an update or not.
>   * To let the clients find the update, the directory with the
> script's name ("greatscript" in the example) must be identical on the
> server and in Amarok's script directory.
>   * If an evil hacker takes over the server amarok.kde.org and puts
> harddrive-wiping code into all of the scripts stored there (and
> increments all version numbers), the installed Amaroks in the world
> will download the updates, try to verify their signatures with the
> public key that's integrated into Amarok, that verification will fail,
> and no update will be performed. As long as the developers who have
> access to the private key keep this key secret, it is guaranteed that
> each update was in fact signed by a developer.
>   * If an evil hacker manages, in addition to taking over the
> server, to change the public keys that are part of Amarok
> installations worldwide to match a private key that he generated
> himself, he would then be able to abuse the updating system for his
> purposes. On the other hand, if he's already managed to change data on
> your hard drive, you're f*cked anyway...
>
>
> F. What about security?
>
> Well, I'm not Bruce Schneier, but as a computer science student I've
> got enough background information to know what I'm talking about. And
> what I say is: As described/implemented so far, the updating system is
> secure. At least, it's what's considered secure by everyone at the
> moment. That means:
> Digital signing is intended to protect against:
>
>   * compromised update servers
>   * compromised connections to the server ("man-in-the-middle"
> attacks, compromised proxies/routers, or simply transmission errors)
>
> and it achieves this protection successfully. It won't and can't
> protect against:
>
>   * trusted devs having their computers hacked or their houses
> broken into, where the private key might be stolen
>   * trusted devs signing unstable/malicious/crappy code because they
> didn't see the code was bad
>   * trusted devs turning over to the Dark Side(TM)
>   * changed public keys on users' computers
>   * brute force attacks; but unless you've got a supercomputer at
> your disposal and several years of time on your hands you don't really
> have a chance to find the private key
>   * a scientific breakthrough that renders current encryption
> schemes weak (extremely unlikely, but can't be ruled out)
>   * earthquakes, so-called terrorist attacks, and the grass getting
> all wet in the rain.
>
> So, relax, these remaining risks are (a) very very small and (b)
> anyway completely unavoidable. If you don't trust the Amarok devs'
> good intentions and competence, don't use Amarok. In fact, it's best
> not to use a computer at all.
>
>
> G. Addendum
>
> Apparently I haven't made it entirely clear that the updating system
> is intended for the scripts that come with Amarok only; I don't want
> to replace kde-apps.org or GHNS, and I certainly don't want to put any
> additional stress on the hard-working devs. On the other hand, the
> updater doesn't care where a script originally came from, if it finds
> a version number in the first line, it looks for updates; so if you
> ever decide to cooperate with 3rd-party script authors on the updating
> mechanism, no change to the code would be required, it would just
> work. Generally, I consider the system lightweight (maybe with the
> exception of the extra library requirement) and easy-to-use. The part
> that goes into Amarok is about 100 lines of code.
>
> Any thoughts? Any help? Of course, I can immediately publish my source
> code, if anyone wants to look at it.
>
> Regards,
> Jakob
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>

-- 
Regards,
Peter Zhou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok/attachments/20090908/a11aa098/attachment.html>