Automatic Script Updating... Discuss!

[Catch-22]

Forgive me for not reading the entire thread, but isn't this technically already possible using file_to_map() and a bit of trickery?

 

[slyz]

map_to_file() shouldn't be able to write to Mafia's /scripts folder.

 

[Catch-22]

string [string] my_code;
buffer execute;
file_to_map("http://myserver.local/code.txt", my_code);
foreach line in my_code {
    append(execute, line);
}
cli_execute("ashq "+execute);

This proof of concept doesn't need to write to the scripts folder. I'm not sure if it will work though

 

[slyz]

I hadn't thought of that

I think the script would need to be formated in a certain way so that file_to_map() can work, but it would be a nice workaround.

 

[StDoodle]

Yeah, I've actually contemplated that before, and even toyed around with it a little. There are some major complications; line breaks, tabs, and special characters can get tricky, and it's a royal PITA getting any heavily htmlform.ash-dependent script working, but it can be done. If I had reliable hosting I'd probably have played around with this some more.

 

[bordemstirs]

string [string] my_code;
buffer execute;
file_to_map("http://myserver.local/code.txt", my_code);
foreach line in my_code {
    append(execute, line);
}
cli_execute("ashq "+execute);

This proof of concept doesn't need to write to the scripts folder. I'm not sure if it will work though

Funny, I'd actually been kinda working on something to load scripts via file_to_map. PITA to write, of course.

(that's actually a broken post, hadn't fixed the line numbers before saving, but fix is easy.)

 

[Catch-22]

Although I'm always up for a scripting challenge, I wouldn't really support an automatically updating script, at least not in the way it has been proposed so far. It introduces security risks. You might trust a scripter not to add malicious code to their script, but do you know how secure their host is? Even if the server is only compromised for a few hours, if you're a popular script writer that's potentially hundreds of users that could be affected in that window. I'm sure if some sort of grand swindle were to ever take place, the powers that be would step in and set things right, but I'd rather not take my chances.

Of course, as I've shown, this kind of thing is already possible using existing ASH commands. Having said that, I'd be pretty careful if I ever saw something like that in a script that I was using.

 

[slyz]

That's why an SVN tool would be nice, since you can look at the changes before approving them.

 

[bumcheekcity]

The webserver could diff the files quite easily, so you could inspect differences in files.

I'd be happy to write something if people were in favour of at least having a try at this.

 

[matt.chugg]

Although I'm always up for a scripting challenge, I wouldn't really support an automatically updating script, at least not in the way it has been proposed so far. It introduces security risks. You might trust a scripter not to add malicious code to their script, but do you know how secure their host is? Even if the server is only compromised for a few hours, if you're a popular script writer that's potentially hundreds of users that could be affected in that window. I'm sure if some sort of grand swindle were to ever take place, the powers that be would step in and set things right, but I'd rather not take my chances.

Of course, as I've shown, this kind of thing is already possible using existing ASH commands. Having said that, I'd be pretty careful if I ever saw something like that in a script that I was using.

Perhaps the word automatic is wrong here, it should be "simplified script updating" NOTHING would be changed without consent of the user first. Consider it in fact automation of the download and installation of new version of scripts, saving time and effort for both the script writer and the end user

How is the security of the script writers host any more relevant than it is already? they are simply using a different system to publish their scripts, securty wouldn't be any less than publishing on kolmafia.us using vbullitin.

Do you diff new versions of zlib, bales recovery, zarqons smartstasis, I know I don't, I trust those particular writers and others. Of course new scripts i'll check, especially from new script writers. Do you compile kolmafia from it's source, after checking every line thats been changed?

I think using ash commands to accomplish this would actually make things much less secure, having a script able to update its self, or having the ability for a script to download and execute DYNAMIC code (even if it is sandboxed to the kolmafia environment) is much worse than a system that could update scripts selectivly from a trusted source (fewyn has already offered us an SVN server on this host.)

I'm not trying to start an argument, but I can't help feeling that some of the negativity regarding security concerns is unfounded.

On the whole i'd say response has been positive, with most people feeling that something would be good, if we could work out quite what it would be. I'd like to see veracity, jason and hola weigh in on this, for 2 reasons, one because I value their opinion on anything kolmafia related, and 2 because they may have some interesting ideas on implimentation (no-one should take this as saying I don't respect their opinion, everyone else has already made their points! and fron...ax has spent some of his own time looking quite hard at an SVN solution (thanks))

 

[Catch-22]

How is the security of the script writers host any more relevant than it is already? they are simply using a different system to publish their scripts, securty wouldn't be any less than publishing on kolmafia.us using vbullitin.

It's just an additional attack vector. For KoLmafia currently I download from sourceforge.net, builds.kolmafia.us, and kolmafia.us. That's 3 attack vectors. When you start adding netnoob.homelinux.org and maliciousdude.freedns.afraid.org and all sorts of other potential targets into the mix, I'd say security does become more of a concern.

I think using ash commands to accomplish this would actually make things much less secure, having a script able to update its self, or having the ability for a script to download and execute DYNAMIC code (even if it is sandboxed to the kolmafia environment) is much worse than a system that could update scripts selectivly from a trusted source (fewyn has already offered us an SVN server on this host.)

This is exactly what I'm talking about, technically it's already possible.

I'm not trying to start an argument, but I can't help feeling that some of the negativity regarding security concerns is unfounded.

I think you mistook my concern for negativity, I'm merely trying to add my 2 cents on perhaps things people may not have considered amongst all the excitement of making life easier.

 

[Theraze]

Well, you're still downloading from kolmafia.us, it's just an additional SVN server running on this site...

 

[fewyn]

I am happy to tell you I have *yet* to have the server hacked.

/knocks on wood.

 

[Catch-22]

I am happy to tell you I have *yet* to have the server hacked.

/knocks on wood.

Haha, as far as you can tell, that is

Allow me to clarify my position. I'm opposed to scripts being able to dynamically, without my explicit knowledge, execute code from any old server on the internet. If it can be done properly, in an environment where script authorship can be verified, where the host is at least somewhat reputable (ie. kolmafia.us) and where the user is at least made aware that there's been changes made to the script, then it's not as bad.

 

[bumcheekcity]

So, any further thoughts on this?

 

[fronobulax]

So, any further thoughts on this?

I lost interest for three reasons. First, no one really asked for a feature that was not available in a SVN client and so my "Do Not Reinvent The Wheel" kind of kicked in. Second, the easy solution - integrating an existing SVN client - required a change in the supported version of Java. Third, the same kind of mindset on the part of script authors that has some scripts hosted here, some at SourceForge and some in other places and has some folks use mafia parameters and others use zLib variables suggested to me that the adoption rate of any solution was going to be low compared to the effort involved in implementation.

That said, if Hola's jstack use remains a fundamental feature then the Java version will change and integrating an existing client seems to me to be an interesting task so I'm pretty much waiting for an official statement on the Java version and then will rekindle my interest.

I don't recall any of the other devs expressing interest or having time to kill so I'm responding as if I would have a major role in the implementation. However I'm fine if someone else wants to take the lead.

 

[matt.chugg]

I lost interest for three reasons. First, no one really asked for a feature that was not available in a SVN client and so my "Do Not Reinvent The Wheel" kind of kicked in. Second, the easy solution - integrating an existing SVN client - required a change in the supported version of Java. Third, the same kind of mindset on the part of script authors that has some scripts hosted here, some at SourceForge and some in other places and has some folks use mafia parameters and others use zLib variables suggested to me that the adoption rate of any solution was going to be low compared to the effort involved in implementation.

That said, if Hola's jstack use remains a fundamental feature then the Java version will change and integrating an existing client seems to me to be an interesting task so I'm pretty much waiting for an official statement on the Java version and then will rekindle my interest.

I don't recall any of the other devs expressing interest or having time to kill so I'm responding as if I would have a major role in the implementation. However I'm fine if someone else wants to take the lead.

Pretty much what Fronbulax said, I still think it would be a good feature, but wouldn't need any of the coding I could put in if we were using svn server. I'm still happy to help in any way I can.

 

[bumcheekcity]

Instead of using SVN, would it be possible to use a PHP script on a third party server to which people would upload files?

As it would be optional, I can't see people having problems, and if they did, it would be optional, so it wouldn't be an issue, they could still download via kolmafia.us?

 

[fronobulax]

Instead of using SVN, would it be possible to use a PHP script on a third party server to which people would upload files?

As it would be optional, I can't see people having problems, and if they did, it would be optional, so it wouldn't be an issue, they could still download via kolmafia.us?

Anything is possible but not necessarily worth doing or worth adopting if someone else does it. The difficulties are on the client end. YMMV

 

[bumcheekcity]

By the client end do you mean on the Java or PHP side? I couldn't imagine it's that hard to do a quick check for a JSON/XML page on load, compare some strings, perhaps md5() some files for basic integrity checking and download updates from a HTTP connection for Java. I don't program Java, so I would be happy to be told it's not as easy as I think.

I'd be happy to make a PHP page that allows script makers to log in and upload new scripts, and then an api.php page which exports information about the version of the files that have been uploaded. Then the Java file could compare and offer the user an up or down-grade through a nice one-click screen on load.

I think it would transform and heavily increase the use of scripts, particularly the big support scripts, I'm thinking universal_recovery, newLife, etc. as well as the frequently updated turn-burners, my ascension script, the nemesis and basement ones, etc.