Zugg Software :: View topic - Feature request: Allow the XML parser to execute commands

Apprentice Joined: 22 Mar 2009 Posts: 149

When putting together scripts for zMud, it was very easy to include a #DELCLASS line near the beginning of the .zsc file which, when imported, would remove the class the script was installed in, effectively uninstalling any previous versions before updating to the current version. This was very simple to set up and allowed me to make revisions to scripts which people who didn't understand zscript at all could still import and use with minimal fuss. It was also very easy to include a #SAY line at the end which echoed a message, telling the user that the script had been installed and what version they had. Again, super easy and incredibly robust.

Is there a simple way to do the same sort of thing with .xml formatted scripts imported in to Cmud? Possibly xml tags I can stick the code in which will cause it to execute immediately?

Wizard Joined: 26 Mar 2008 Posts: 1547

You could always create a 1 second or half second alarm trigger that would essentially fire after the settings have been saved and then in the trigger run anything you need to run for an "onInstall" procedure.

Apprentice Joined: 22 Mar 2009 Posts: 149

Posted: Sat Feb 19, 2011 2:12 am

You can't do it with the XML import, sorry. That would make it too easy for somebody to install Malware into your system or scripts. The whole purpose of the XML is to provide a plain-text way to look at scripts and copy/paste them. There isn't any way to make XML text like this "auto execute".

As Chamenas mentioned, you *can* set up an "onLoad" event handler in your script that can take action when you first load/execute the script. This can't happen when you just Paste the XML, but it will happen when you next the session containing the package. It would be pretty easy to set up a variable or class folder naming scheme with the version of your package and then have the onLoad event check for the old version and remove it.

Or you can use the Shared Package Library which is already set up for this kind of stuff. You just update your package in the library, and then people using the package will get an Update status when they update the library and can then download/install the new version. When doing this, CMUD will remove the old version and replace it with the new version. So yes, CMUD *does* make it easy if you use the built-in solutions for it and not try to make it work like zMUD.

Apprentice Joined: 22 Mar 2009 Posts: 149

Is there any way you might reconsider adding the ability to 'auto execute' code, as you put it, in to the XML parsing engine? The ability to tailor scripts in XML format so that they can both execute instructions and create settings on a users system would make the import engine much more flexible and make it a great deal easier for me and others to distribute and troubleshoot scripts for less technically inclined users so that the end user only needs to do one thing, not a series of steps in a particular sequence.

Magician Joined: 28 Jan 2007 Posts: 430

Just my two cents but the apparent reluctance to use Package Library would be easily solved by coding some sort of security mechanism within the upload process. That way no-one unfamiliar with a, say, password wouldn't have access to it. Problem solved.
However, I'm not actively mudding nor using CMud anymore so perhaps there is such an option already.

Either way, some food for thought.

Wizard Joined: 22 Mar 2007 Posts: 2320

Actually, using the Package Library _would_ solve the problem of someone accidentally mucking up one of the scripts, because the entire package would be overwritten when they reload it from the library. So you haven't actually shown any problem that is not solved by the Package Library, except that the scripts become public and you can't restrict who can get them.

No, the XML should absolutely not, never, ever, be changed to allow <execute> commands from within the script. Zugg already pointed out that if he did that, someone could write code that would essentially act as a trojan horse on your computer. Zugg really doesn't want the liability associated with that.

Apprentice Joined: 22 Mar 2009 Posts: 149

That would help resolve the problem with the availability of scripts, Progonoi, but I have to imagine it would be a larger undertaking to code that sort of system in to the package library than it would be to change the XML parser. There are also situations in which keeping a script secret is as important as restricting who has access to it. In those situations, you don't want the script showing up on a publicly available and searchable listing. So, again, just expanding the functionality of the XML importer seems more effective.

Wizard Joined: 22 Mar 2007 Posts: 2320

It is more than a half-second delay. It delays execution until you have a chance to actually examine the code. Putting an <execute> code into the XML would cause it to activate as soon as you loaded it--not even giving you the chance to examine the code! In fact, the code could be written to do something to your system, and then _change_ its own code to something harmless, so that when you examined the code, you wouldn't realize that it had done something malicious. It is an incredible security risk. In the current system, you always have the chance to examine the code before you use it in Cmud.

Apprentice Joined: 22 Mar 2009 Posts: 149

Are you using the same import XML function that I am, Rahab? The one I use requires that I, the user, actively copy and paste from some other source or save an XML file before importing it in to Cmud. This act of copying and pasting text or saving a file to my computer prior to importing it will ALWAYS provide me with an opportunity to examine the XML. Malicious code embedded in XML cannot circumvent these steps by the user which give them opportunities to examine the XML... So no, the situation you describe in which XML could be installed on your system through Cmud without any opportunity to examine it is impossible. That can't happen.

It would not be an "incredible security risk" to allow imported XML to execute instructions. Including that functionality in to the XML parser would make it effectively as secure, and effectively as insecure, as the XML import function is right now. To put that another way, the change I am proposing will make no difference to the security or insecurity of the import XML function... It would just be really useful and make various tasks much simpler.

Wizard Joined: 22 Mar 2007 Posts: 2320

The more usual method of XML import is to use the Import XML function. This _would_ have the problem I described, as would using the Package Library. You are not using the normal methods for importing XML to Cmud, so while that functionality might be good for you, it would be potential disaster for everyone else.

Apprentice Joined: 22 Mar 2009 Posts: 149

Help me out here, Rahab... What 'Import XML function' are you talking about? How do navigate to it and use it? The normal method of importing XML that I use is navigated to by opening the Cmud Package Editor, then clicking on 'File', selecting 'Import XML' and then selecting a file I previously created or downloaded. The other method of importing XML that I use is to copy XML from someplace like these forums in to my windows clipboard and then paste it directly in to the Cmud Package Editor. By using either of these methods, I always have an opportunity to review the contents of the XML before installing them. What method are you using that circumvents the opportunity to review the XML?

You're right in saying that using the package library will install packages without giving the user an opportunity to view them first, but that is a vulnerability in the package library itself, and I'm not even sure if the package library uses XML at any point. That vulnerability in the package library could be exploited right now. The feature I am requesting will not make it any more vulnerable to malicious code.

Here, I'll give you two examples:

Example 1 (the XML parser as it works now)

Wizard Joined: 26 Mar 2008 Posts: 1547

I'd like to know what people are talking about as well. As DraxDrax points out, the only scripting allowed in the <EXECUTE> tags would be zScript code, which, while it could possibly contain something malicious is no different than the fact that any normal zScript code could contain something malicious. And, as mentioned, you always get a chance to see what's in the code. Now, if it's a specific worry with the Package Library, you could always have it function that packages in the Package Library can't contain <EXECUTE> tags, I suppose.

Apprentice Joined: 22 Mar 2009 Posts: 149

I don't think the package library even stores anything as XML. It saves and transfers packages as .pkg files.

Not sure about that though.

Wizard Joined: 22 Mar 2007 Posts: 2320

Yes, the Package Library saves things as .pkg files, I believe. The .pkg file is an SQLite format. However, when you load the package from the Package Library, the XML Parser still has to parse the XML from within the SQLite database.

You do have a point that someone could put such an alarm into a package. I have a vague recollection that there was a discussion about this a long time ago. You can prevent that problem by turning triggers off before loading the file. I'm sure almost no one does, but that is a solution if there is a concern. Do you have a similar mechanism for your proposed <execute> tags?

Apprentice Joined: 22 Mar 2009 Posts: 149

Wizard Joined: 22 Mar 2007 Posts: 2320

This <execute> is only supposed to be encountered in XML that is manually altered? But you aren't supposed to do that. Zugg has said before that we should not edit the XML code. Doing so is a good way to corrupt a package.

Apprentice Joined: 22 Mar 2009 Posts: 149

Files which are generated with the 'export to XML' feature or copy/pasted from the package editor will only ever generate XML that creates settings which reside on your Cmud session. So, things like aliases, variables and triggers etc. The entire point of the <execute> tag is to have a means of executing zScript commands at the time the XML is imported that will not create settings which reside in your Cmud session... things like an executed #SAY command or #DELCLASS or #BEEP. Those commands are executed and leave no settings behind. So, indeed, this would always require that XML be manually edited if it's to include <execute> tags.

That's the whole point, Rahab. I've said this a few times now. You seem to be confused about a number of points and I'm starting to wonder if going over them again and again for you is actually accomplishing anything.

I haven't seen Zugg say that manually editing XML is something we shouldn't ever be doing. None the less, I routinely edit XML files or snippits of XML code for various reasons. It's possible to make mistakes and create bugs or corrupt settings in this way, but that's true of absolutely every means of creating/altering code.

See the two examples of XML I posted two or three comments back? Both of those were manually edited. One, obviously, because it contains tags that don't exist, and the other because exporting an alarm trigger that only exists for half a second isn't very easy to do. I also removed the copy="yes" data that was unnecessary. It's very common for people to remove the <?xml version="1.0" encoding="ISO-8859-1" ?> tag from the beginning of XML, or the <cmud></cmud> tags, as these appear to be unnecessary when importing XML but are always generated when you copy/paste or use the export XML feature. Sometimes you spot issues in the XML and edit it directly, rather than changing your Cmud settings and exporting it all over again...

If you're not confident enough with zScript code or XML tags to be comfortable manually modifying XML, the proposed <execute> tags aren't for you. If, like me, you feel you have a solid grasp of these languages and formats, it would be a very useful addition and make Cmud better.

Wizard Joined: 22 Mar 2007 Posts: 2320

At this point, I am pretty sure that I do understand what you are saying. I simply completely disagree that it is a good idea. And I was pointing out that Zugg has said that the XML code is not intended to be modified and is not supported. I myself am quite confident that I could edit it, if I chose. But it is not a supported feature of Cmud. There are other ways of achieving the ultimate goal that you want (supporting upgrades for people using your package). I have used several methods myself.

Perhaps you would be interested in the OnLoad event?

Apprentice Joined: 22 Mar 2009 Posts: 149

Sadly, the onLoad event has not become a more viable solution since it was first mentioned in this topic three days ago.