Scripts containing XML-escaped characters not handled properly

[grahampugh]

Hi Shea, I guess this is an artefact of the new script-uploading process in v.1.0.0, but it appears that a script that contains a < or > doesn't get uploaded correctly, as they appear in the JSS with < and > respectively. This impacts code that quotes any XML, but also anything that uses these for variable import, <<END, 2> /dev/null etc.

[qu1gl3s]

Hi Shea,

I'm also experiencing this issue as I have some XML tagging in my scripts needed for licensing files.

[brodjieski]

I'm seeing the same issues after upgrading to the latest JSS importer. I'm on an older JSS (9.99), so I'm not sure if JAMF Pro handles the import of scripts via the API any differently.

In testing, I changed the method that handles the scripts to not escape the XML, which seemed to do the trick... but I'm not sure if it breaks anything else.

[sheagcraig]

@grahampugh, @qu1gl3s, @brodjieski can you give me some examples?

We used to upload script files by copying the files themselves onto DPs. Then we had to use an unsupported method to dbfileupload them. However, now you just put the script in the XML that you post to the scripts endpoint. The API only accepts XML for object creation or updating, so we have to upload the script as XML. < and > are reserved characters in XML, you can't just have them raw in the XML without causing a parsing error.

Are you sure this is a bug with JSSImporter and not with the Jamf Pro API?

Can you curl a script object with these characters left in the scripts?

Also, just because they show up on the JSS encoded, what do they look like when you then retrieve them? I mean, I'm sure they're still encoded because they would have to be to be valid XML.

I would hope that the Casper agent executing these scripts would know to decode prior to execution!

[grahampugh]

I suppose this depends on how the scripts are inserted into the XML by JSSImporter. In modern Jamf Pro, scripts and extension attributes are handled exactly the same way, but in JSSImporter there is a disparity. The expectation is that the script is a separate .sh file, which is referred to by the ScriptTemplate.xml. With EAs there is only an ExtensionAttributeTemplate.xml,, with the script embedded within, and the expectation is that you perform the XML-escaping.

I think the way scripts are handled is better (i.e. JSSImporter should do the XML-escaping rather than us having to do so, so we can use a real working script). I'll see if I can figure it out.

[grahampugh]

So it looks like JSSImporter is over-encoding the XML, by doing it twice. Example in this dummy file downloaded via API:

<script>
  <id>41</id>
  <name>LibreOffice-postinstall.sh</name>
  <category>Productivity</category>
  <filename>LibreOffice-postinstall.sh</filename>
  <info/>
  <notes/>
  <priority>After</priority>
  <parameters/>
  <os_requirements/>
  <script_contents>#!/bin/bash
## postflight script

echo "LibreOffice installed" &amp;gt; /tmp/LibreOfficeInstalled.txt</script_contents>
</script>```

I suspect `escape()` is being called twice, and I read that `xml.sax.saxutils.escape` doesn't handle that well (https://stackoverflow.com/questions/1546717/escaping-strings-for-use-in-xml). Will verify this.

[grahampugh]

Solved by #135