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