Rash - Remote Ash Scripts

[Paragon]

RASH.ash

http://www.paragon.net84.net/Kol

What is it?
Rash is a script that enables ash scripts hosted on a remote repository to be run locally.

Why would I use it?
When scripts are updated on the rash repository, the newer version will be detected and can be used automatically on the local machine. Also, the original script doesn't need to be on your local machine. Personally, I use kol on multiple computers, my desktop and my laptop, keeping track of what version I have on which machine can become annoying, using rash I can know that the same version of the script will be run no matter which Mafia directory on which machine I run it from!

Is it safe?
Safety is subjective... however there are a number of precautions taken that in my opinion make rash safe to use.
First, users must register to upload files (you do not need to register to use any scripts) to the rash repository, those users can then be verified. A user is verified, by contacting me on this forum. Once a user is verified it is safe to assume that the person representing a username on the rash repository is the same person representing the same username here on these forums. You should not run scripts posted by unverified users unless you view the source each and every update. Also note, that being verified does not guarantee the uploader is not malicious, you should only trust the verified user as much as you trust the same user from this forum.

Second, whenever a new version of a script is detected rash gives you the option of viewing the source before caching and using the source. The source is displayed in a reasonably formatted way such that reviewing the source should not be too difficult. The source that is shown is the source that is stored in your local cache and you can be sure that the source that you reviewed and accepted is the source being run until a new version is detected, in which case you again have the option of reviewing the source. You can also decline an update and continue to use the older source.

Third, sources imported into a script are kept individually, therefore if a library that a script depends upon is updated you will be notified, and allowed to view the source of the new version of the library.

Fourth, only the user that uploads a script are given permission to update that script. If a verified user has uploaded the script, you know that same user is the only user applying new versions.

Finally, by default the script will not run source that has just been updated, you will have the option to review the source, via the view command and rash will only run cached source.

How do I use it?
Once you download rash into your script directory you can type rash <command> into the CLI.
Commands:
List [+verified] [filter]:> List all scripts on the rash repository, using the +verified flag shows only scripts uploaded by verified users, supplying a filter will filter by uploaded name and script name
View scriptname :> views the cached version of the script

The list displayed contains the script name, the name of the user that uploaded the file, an icon to indicate if the user is verified, the date the script was last updated and the comments left by the script uploader the last time the uploader updated the script. Clicking on the name of the script follows the link to the human readable, current source of the script.

rash scriptname [Script parameters] :> Calls the script the same as if you had the script locally and had used the call command.


As a script writer, what do I have to do to make my script compatible?
There are only 2 things to consider when deciding if your script is rashable.
First, a rash script *can* be run without a main function... but it causes a pop up to appear so It is highly recommended that you use a main function.
Second you cannot denote comments with a # character. (This may be fixed with future .php scripts, but currently it is a minor inconvenience with a trivial work around
Beyond those two issues, just register, upload and run.

Change log:
1.01 fix issue with a greedy vs. lazy regex that caused some scripts to work incorrectly
1.01 fixes to correct an issue with the rash cache.
1.02 Add RASH_Run_New_Source property default to false
1.02 Add View command to view cached source
1.02 Add capability to view the php source for viewSrc.php, upload.php and uploader.php
1.02 Add ability to filter list
1.03 Correctly handle notification commands, including setting script name.

 

[Paragon]

Ok, So I did a bunch of work on the site, and rash it's self. Visitors can goto http://www.paragon.net84.net/Kol to see what scripts are available in the repository,when they were last updated, and to register to upload scripts to the repository. Users can only update scripts that they have uploaded themselves (in the future I would like to make users be able to share upload ability but I just havn't added that page yet.) The site is username/password protected so you can be sure that the person that says they uploaded the file was the one that did so. I also left the directory that the scripts can be downloaded from open for public browsing so that you can look at the actual script that will be/was ran.

Calling rash with the argument list, will show the list of rashable scripts, along with the uploader and time of last update.
Rash will now work with scripts that import libraries, and if those libraries import libraries it should still be ok (There may be an issue if source files a and b *Both* reference source file c).
Rash will now accept parameters if the main function accepts parameters.
Rash can work to run a relay script... however the either 1) Files such as .css, .js, or img files need to be either local, or fully qualified to work properly. Below is an example of rashing a relay script

import <rash.ash>
void main()
{
   rash("Rash_Relay_test");
}

@Zarqon: I uploaded zlib because it is a large, very non-trivial library for testing and demonstration purposes. Please let me know if you a) Want it taken down, or b)Want upload access back.

rash smlib : Demonstrates library importation
rash parmTest: takes three arguments an integer, an item and a slot, displays nonsense based on inputs.

The intersting part is that it requires no special coding or conventions on the part of the script writer for rash to work correctly, for example the exact code of the uploaded file for parmTest is as follows:

void main(int qnty,item it,slot slt)
{
    string q="have at least";
    if (it.available_amount()<qnty) q="don't have";
    print("You "+q+" "+qnty+" "+it+" to put in your "+slt);
}

 

[Catch-22]

Unfortunately you put a lot of work/effort into something that nobody should really be using. If you'd read the post on automatic script updating I linked to in your earlier proof of concept thread, you'd understand why (you'd also see that the same techniques had already been shown by myself and bordemstirs).

 

[Paragon]

I am not sure what link you are talking about, I looked through the other thread again and didn't see anything like what you are talking about. Could you please link it again, or elaborate?

Also, this method does not load anything onto your local computer so there is no file writing/overwriting. Also, since a user can only update scripts that they have originally uploaded you can trust the script as much as you trust the user. Rash works differently then original concept in the other proof of concept thread.

 

[Catch-22]

Well you used visit_url instead of file_to_map, but still the concept is the same. The issue with loading from a remote server is your server could become compromised and someone might be executing a malicious script without their knowledge. The issue becomes compounded when you're also running imports remotely, such as zlib. Can you imagine if someone managed to edit zlib to put their own stealth malicious code inside it? Nobody would be able to tell, at least now people can review the scripts before they run them (understanding what's actually happening is another thing).

 

[Paragon]

I thought about the issue of someone changing the script to be malicious and corrupting the server side version, which is why I put precautions into place. There are two in place at the moment, first a script can only be updated by the person who uploaded it. Second, the source code is available for viewing to everyone. While your argument that the server could become compromised is true, that also holds for firefox script repositories, or even Kolmafia's SVN repository. The site i made may not look like much, but it is protected with standard cryptography, using one way salted password hashes and all that sort of thing, and the sql is all parameterized so the should be no risk of sql injection etc. etc.

 

[Theraze]

But your example shows one of the very problems... there's no guarantee that the actual maintainer of the script will be the one who uploads it. What's to stop Catch-22 or myself as signing up as Bale or zarqon? Yes, only the person who signed up has update rights... but nothing guarantees that they're the right one.

Similar, with current scripts, if I update TheSea, people have to download and validate that they actually want it to be updated and that they like the new settings and changes. With your remote hosting, if they're using remote scripts, they don't even have a notification that anything has happened.

For that matter, if I have personal changes, for example me wanting Bale's NewLife script to set my HP restoration to .65/.95 instead of .05/.95, if I were using a remote version of his script, I couldn't keep my copy without uploading my own copy onto the server. With the talked about version on the page listed, if we actually have scripts using a SVN repository, it would be able to merge my changes into the script instead of losing them...

 

[Paragon]

The User name of the person who uploaded the script is shown with the name of the script. I can add a field for "Verified", so that if a user sends me a pm on this site I can update their verified status on the repository. I can also add a rash list verified command that will list only scripts uploaded by verified users.

The concept is for the people who DO want the newest version, or at least easy access to the newest versions at all times. If you are the type of user who customizes all the scripts you download then you may not be interested, however if you are the kind of person who doesn't want to have to see "This script is out of date", then follow the url, then download the file, then move it to the scripts directory then it may be the script for you. Besides, I don't think that rash should be the only script in your scripts directory (although potentially it Could be).

 

[Theraze]

I don't customize all of them, just some. I'm just saying that despite wanting to have a solution for remote access scripts, I'm unlikely to ever actually use the one you've provided so far.

Both because I want to know what the script is doing as it's easy to have things go wrong with a minor typo, and because I want to know when a script is updating rather then just having it all happen silently in the background and keeping me unaware that I'm missing out on new functionality...

 

[Catch-22]

Credit to you for trying to fix a problem, but the solution really is some kind of localized version control, such as a built-in SVN client (as has been proposed in the past). It seems like you have at least some programming knowledge, and you certainly have the desire to provide a solution, so why not simply redirect your motivation?

 

[Paragon]

Ok, the new version has the following changes.

Rash list :> List all rashable scripts
Rash list verified:> list all rashable scripts uploaded by a verified user.

The is now a cache of rashable scripts, such that the new version is only downloaded when there has been a new version.
If a new version is detected, you have the option to view the code, then you have the option to use the new version, or to use the old version, finally if you choose to use the old version you have the option to ignore the new version until and even newer version is available or to be alerted of the change again next time you attempt to run it.

I almost forgot, scripters can add a comment (upto 1000 characters) about changes with the new version, that rash uses will see when the script detects a new version of the script being run.

 

[fronobulax]

I think the real issue is you have implemented a solution to a problem that no one else really agrees is a problem or perhaps agrees is the right problem. The whole issue of malicious compromise of the remote server is a red herring. At some level every argument made here could also be made as an argument against using Windows Update, for example, because some people don't really trust Microsoft and they have been hacked.

Balancing the security risks and the cost of over coming them what I want is a system that a) lets me know something is newer than what I have and b) lets me download and inspect it before it ever gets run. This latter step is important because I may have local changes I want to incorporate before I run it.

I don't see rash doing that and no more. I do see rash introducing some irrelevant security holes that might not have been there before IF the user is the sort of person who trusts the user name "bale" and does not actually inspect the code that user name "bale" posted and wants you to run on your machine. But my primary security defense is to look at what I am about to run or just not worry.

I'll be glad to pat you on the back for a reasonable execution of an interesting idea but I doubt that I would use it myself. Given my estimate that there are about 10 people who actively maintain scripts this is a lot of effort for a very small user base. Your target audience is really the script writers and not the script users.

 

[Bale]

I do see rash introducing some irrelevant security holes that might not have been there before IF the user is the sort of person who trusts the user name "bale" and does not actually inspect the code that user name "bale" posted and wants you to run on your machine.

Turns out that someone really did create a user name "bale" and uploaded a version of one of my scripts there. But that "bale" was not myself. I was not amused. Paragon gladly turned that account over to this to prevent it from potentially being used for mischief in my name.

 

[Paragon]

Ok, So I think I have addressed the security concerns, everything from being able to trust a user to having easy access to script source has been addressed. Check out the OP for a full rundown.

 

[Grotfang]

you should only trust the verified user as much as you trust the same user from this forum.

you should only trust the verified user as much as you trust Paragon.

I realise you have put ever increasing amounts of work into this, but I don't think this is the right solution to the problem you are trying to fix. Fronobulax sums it up nicely. There are better, more robust solutions that also keep control firmly in the hands of the end users. If you really want to help, maybe you could focus your energies on implementing those.

 

[Paragon]

I hate to sound like I am kicking a dead horse... but I am really not seeing any legitimate security concerns. You might as well say that you should only trust Kol mafia as much as you trust veracity, or any of the other users with commit access... sure you should only trust rash as much as you trust me... you should only trust OCD as much as you trust winter bay, you should only trust windows as much as you trust windows...

Other solutions do exists... if you want to use another tool, like a svn client or some other .exe, but no other tool (other then built in mafia support) will allow this to be done at the ash level... to be integrated as completely. I don't have the commit access, and even if i did my expertise is in c# rather then java... I could make an executable that does pretty much the same thing, but then you'd Really have to trust me unless you wanted to decompile the code... seriously though, every line of code is completely visible to the end user, the end user can stop the process at any point.

 

[Bale]

I hate to sound like I am kicking a dead horse... but I am really not seeing any legitimate security concerns. You might as well say that you should only trust Kol mafia as much as you trust veracity, or any of the other users with commit access... sure you should only trust rash as much as you trust me... you should only trust OCD as much as you trust winter bay, you should only trust windows as much as you trust windows...

Quite correct except that OCD is mine, not Winterbay's project.

Other solutions do exists... if you want to use another tool, like a svn client or some other .exe, but no other tool (other then built in mafia support) will allow this to be done at the ash level...

Yup. The ideal solution for this feature would actually be this which I believe is currently a fronobulax project.

 

[Grotfang]

I hate to sound like I am kicking a dead horse... but I am really not seeing any legitimate security concerns. You might as well say that you should only trust Kol mafia as much as you trust veracity, or any of the other users with commit access... sure you should only trust rash as much as you trust me... you should only trust OCD as much as you trust winter bay, you should only trust windows as much as you trust windows...

The security isn't the main issue here, you are right. But what you say is not entirely true. KoLmafia, being open source and all, is a whole different ball park. I get to change the code to my liking and blend the main code with mine to make it my software. Trust isn't a part of it at any point. The same goes for the other scripts you mention. Once the document is on my machine it is static and I know exactly what I'm running. I can have as little faith in Bale as I like and still comfortably run his script. As soon as I run your script, near as I can tell, I am depending on the code your server returns being safe for me to use. There is sufficient difference between the URL your script uses to retrieve the code it runs and that used to display code that we can browse to mean that anything could be served. I agree that it is unlikely, and a savvy user could certainly verify that the returned code was identical. However, at the point at which I have checked that your service is not going to harm me, I would have probably been just as well off downloading the file.

Either way, this is purely academic. I am sure that your server is returning the correct script and that my concerns exist only in my mind. In reality, I think this would operate perfectly well.

 

[fronobulax]

I hate to sound like I am kicking a dead horse... but I am really not seeing any legitimate security concerns.

I'm afraid you missed my comment about the security concerns being a red herring.

 

[Paragon]

@Grotfang: I have now made the entire process visible, you can Rash upload.php, uploaoder.php and viewSrc.php to view the source of the php scripts that drive the server side file saving and such.
Also, I added a preference that will not allow scripts that have just been downloaded to run, the script must already be in the cache to run. I also added a view command so that you can view the cached version of the script.

I just uploaded what I believe to be the final version of rash, notable new features include a method to filter the result of rash list, and the ability to view cached script source and the ability to restrict rash from running any script that is not already cached (Therefore giving you a chance to look at the exact code that will be run before doing anything)

You still can't customize the code, but that is out of scope as far as I am concerned.