Suggestion to add encryption jar files to iomclient folder

[Deasetopia]

Hi,

After many attempts, I was finally able to connect to SAS via saspy and I'm thankful for all the hardwork done and the new flexibility.

Update request: Can the default rutils needed to authenticate saspy to SAS be added to the iomclient folder by default?

I am about to deploy this to new team members and I am worried about errors when copy/pasting. I also don't think scripting a solution will be scalable for users due to factors like different mounted drives on different VMs, and variations in virtual environments.

Thank you!

[tomweber-sas]

Believe me, I wish I could put those 3 jars in the deployment! That would solve a lot of problems for users! Unfortunately, our legal department identified these as being restricted by import regulations such that they cannot be provided openly; only to customers (these are in a SAS deployment) or via download from our site that has appropriate legal constraints to cover compliance. Just getting the 4 usual jars that everyone needs (with or without the rutil ones), took a number of years to get permission to add to the repo. That solved the whole classpath and jars manual configuration for everyone who didn't have the requirement for the other 3 jars. As of the beginning of the year, this has hit all SAS ODA users too. ODA upgraded to SAS 9.4M7, and that change caused the 3 jars to be required in the deployment (they weren't before and so no manual intervention by users was needed). It would be great if I could put them in the repo so no one has to deal with this manually, but I just am not allowed to. At least, the only thing you need to do is simple copy them into the correct directory, and SASPy will handle the rest; it's preconfigured to use them in the classpath; you don't need to do anything but put them in there. Tom

[Deasetopia]

Thank you Tom for explanation. I do see the cpath modifications in the sasioiom py file, which is appreciated.

To close out, what should we expect of future versions of saspy regarding versions of the 3 jar files? Currently the deployment has sources from ___v940m6, so if there are updates to sas for m7, m8, etc. will i have to copy/paste again. I assume security doesn't usually retrofit or backward compatible

Additionally, if changing/updating saspy, will pip modify/overwrite the "iomclient" directory?

[tomweber-sas]

Hmmm, I haven't seen any compatibility issues with any of the jars (forward or backward), so let me try to investigate that a little more before giving you an answer on that. I don't have every combination, but I think I can try out a couple. The 'I think' answer is that they are all compatible, but let me investigate a little and give you the 'I know' answer instead. FYI, they aren't security jars (which would change perhaps), but rather encryption, which hasn't changed for the types supported, in who knows how long. So they probably are compatible, forward/backward except if there a new type in a newer version of SAS that's not in an older jar. Though I'm not sure that has happened either.

Short answer for the 3 jars is they won't be removed if you upgrade saspy. They'll be there after upgrading. :) Longer answer follows: As for updating SASPy, the best way is to uninstall then install current production version, which is accomplished like this:

pip uninstall -y saspy
pip install saspy

when you do this, pip will leave the saspy install directory structure intact, only deleting the things that were installed from the saspy repo. So, for instance, the sascfg.py example config file is part of the repo, so it is installed. But, it will be deleted by uninstall, and if there is a change in that file in the repo, even an Update (in place) would overwrite that file. Thus needing to have you're config file named sascfg_personal.py. That file isn't in the repo, so uninstall/update/install will not remove/modify/nor touch it at all. It will remain, in that directory, as is, so after installing the latest, that will still be there. These 3 jar files, also not being in the repo, will remain unaffected after updating/installing the latest version (or any version) as well.

Thanks! Tom

[Deasetopia]

That's a really great explanation tom, thank you.

I'm asking about the compatibility because given the information here, I will be able to artifact (internally) a personal config template and the three jar files such that a new user/environment can run a batch/sh file to copy the files into the correct directory.

sascfg_personal.py into /path/to/venv/Lib/site-packages/saspy and the jars into /path/to/venv/Lib/site-packages/saspy/java/iomclient

[tomweber-sas]

Good deal, that sounds like it will make this simple for them. I was able to test out a couple combinations (can't do all of them; I don't have all versions configured all different ways). SAS ODA has workspace servers configured to use AES encryption. They recently upgraded to M7 and require the rutil jars. In my current configuration, I have the rutil jars from M6 and that works fine to connect to ODA. I have the M7 version of the rutil jars available for download here: https://support.sas.com/downloads/package.htm?pid=2494 since users now need those to connect (you can grab those if you want, so you already have M7). That of course works also. I also tried the M8 version of the jars (all of them; the usual 4 required and the 3 rutil), and they worked fine too.

So, as far as AES encryption, M6/7/8 rutil jars (and the other 4 too), all work against M7. That's not comprehensive, but I think you can use the ones you have and it sounds like, if there was a requirement to use a newer version if you upgraded your SAS deployment, then you have a simple way to copy in the new jars (though I don't think you'd have to). That would sure be simpler than updating your whole SAS deployment to newer versions, so I think you're in good shape :)

That's still not an 'I know' answer, but it's a 'I'm pretty sure' answer.

Tom

[Deasetopia]

I think the due diligence is enough that if it breaks, I can sleep at night :D

I'll permalink and store an html of this issue in the script folder for backup, but I doubt any issue will arise considering compatibility was considered and sanity checked.

Thank you again tom

[tomweber-sas]

Thanks! If anything breaks, I'll get you back up and running!