<br>On Mon, Nov 2, 2009 at 5:33 PM, Jakob Kummerow <span dir="ltr"><<a href="mailto:jakob.kummerow@googlemail.com">jakob.kummerow@googlemail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> Seems I missed this important thread. Sorry for missing Jakob's hard<br>
> work! I agree that we can use the auto updater for the built-in<br>
> script. But why we need a public/private key validation when we are<br>
> using our own centralized server.<br>
<br>
</div>We need signatures to prevent the injection of malicious scripts into<br>
Amarok by means of taking over our server, or performing a<br>
man-in-the-middle attack, or whatever. The signature makes sure that<br>
wherever an update comes from (compromised server, untrusted network,<br>
local cache/proxy, ...), if it has been tampered with since it was<br>
signed by one of our devs, it will get rejected.<br></blockquote><div><br></div><div>I agree with this. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> For the 3rd party script, I still insist that we should use<br>
> <a href="http://kde-app.org" target="_blank">kde-app.org</a> since the big change would be very expensive. We should<br>
> definetly make gns to support versioning and updating.<br>
<br>
</div>The current implementation allows us to deploy updates for any script<br>
that we like, including 3rd-party (since code-wise there's no<br>
distinction between the two). Of course, this does not in any way<br>
prevent us from implementing an additional, independent updating<br>
system for 3rd-party scripts.<br>
<br>
The main difference I see is this:<br>
Our own scripts are part of Amarok's core functionality, which we want<br>
to make sure is available to our users at all times. If one of our<br>
scripts that uses an external website breaks because that website<br>
changes, I like having the ability to fix it instantly without<br>
releasing a new Amarok version. An automatic updater that simply works<br>
in the background without user interaction achieves just that.<br>
For 3rd-party scripts, the situation is different: We don't create<br>
those scripts, we don't care so much about what they are doing, we<br>
don't fix them if they break, so deploying updates for /them/ isn't<br>
quite as urgently interesting for us. Updating them (semi-)<br>
automatically would just be a convenience feature for users, who so<br>
far have to search for updates manually if they want any.<br>
<br>
Since we can't control their contents/behaviour, I'm also not sure<br>
whether it would be a good idea to update 3rd-party scripts<br>
automatically (think about injecting malicious code again), which<br>
leads me to the following two-fold long-term proposal:<br>
- An automatic updater (more or less exactly as it is implemented<br>
now), using our own server, and our own signatures, to be used for our<br>
own scripts, and, in case we wish to do so, select 3rd-party scripts.<br>
- An information message for the user about available updates for<br>
3rd-party scripts located on 3rd-party servers (such as <a href="http://kde-apps.org" target="_blank">kde-apps.org</a>),<br>
that either says "Please use the Script Manager dialog to perform the<br>
updates" or "Click 'yes' to apply the updates now" or something to<br>
that effect.<br>
<br></blockquote><div>I never doubt the demand for the auto script updater or at least a version checker. But I would really prefer a simple way to do it instead of adding new dependencies and tons of new code. </div><div>
What I was thinking about is an update of GNS, making it supports signatures and versioning. And using GNS doesn't mean we have to use <a href="http://kde-apps.org">kde-apps.org</a>. We can have our own centralized script release platform by using GNS.</div>
<div><br></div><div>I would prefer adding the patch(the updater) to GNS instead of applying directly into Amarok. We can then auto update our built-in script by our own server, and auto update 3rd party scripts by <a href="http://kde-apps.org">kde-apps.org</a> or whatever.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
A case where I imagine we might want to deploy an update for a<br>
3rd-party script on our server would be if we release a new version of<br>
Amarok that changes something internally, which leads to the old<br>
version of a 3rd-party script crashing consistently, and we get sick<br>
of telling hundreds of people on IRC to manually apply the update.<br>
<br></blockquote><div><br></div><div>What I concern is not where we put the upgrades. But the way we put it. Making new changes will more or less upset the script developers.</div><div><br></div><div>I will have a deeper look at the code committed and try to figure out the possibility of applying the code to GNS(or even make our own copy of GNS for now).</div>
<div><br></div><div><br></div><div>Thanks again for the great efforts made. </div></div><br clear="all"><br>-- <br>Best Regards,<br>Peter Zhou<br>-------------------------------<br><a href="http://www.peterzl.net/">http://www.peterzl.net/</a><br>