I have known about PML Encryption for a long time, and I had always felt that most of the time it was a bad idea. This comes from experience and knowledge regarding code obfuscation: at best it is useless (if someone truly wants to read your code, they will be able to), and at worst it is directly harming the quality of your product.
Despite my objections, I discovered that the central administration team in my company used PML Encryption and would not release the source code for our internal PML applications. I actually heard from some of our subsidiary administrators that they disliked this practice to the point of feeling insulted at the level of distrust coming from our central office. To some extent I agreed, and I thought it introduced unnecessary bureaucracy when requesting modifications and bug fixes to these applications, as we were unable to inspect them in case of failure.
Eventually I joined the admin team and challenged this practice. However, in due time I came to understand why our team made this decision, and why it matters.
But before that: how does PML Encryption work? Well, say you have a nice little PML file. You need to obtain a license from AVEVA to use PML Publisher. Take a PML function:
define function .thisFunctionIsEncrypted( )
write 'This function is encrypted.'
endmethod
You run a command:
pmlencrypt "C:\path\thisFunctionIsEncrypted.pmlfnc" "C:\path\encrypted\thisFunctionIsEncrypted.pmlfnc" -rc4
…and voila! Your file is encrypted.
--<004>-- Published PML 2.2 >--
return error 99 'Unable to decrypt file in this software version'
$** fbcb609d9d57d847f5f27b3de7bd5a3a
$** QrDB5Y18VpwhIV9LuLWGm8rzchQiHuhM+h-IfeqTMaL9XgDE8DpO6rN0br9w
$** eyQtMZXSE+ZstL3jZ+ndTYK5SX6anTbkq-x1AAfcgJKcKncuiaGqzHMrnDDw
$** aPlGcACq4k8x4UZ7uWN2ek3I6lk3QIU4uEpQ1+4IXkQGc9BNUi7Mh557TPzN
$** ZvntqUxY9B+vTR+7PIqFY5Hn4A--XAgTAsS8OwCpfUb7Denjn3TOtUiBszY0
$** Rr0HeLWnVDX+STRBM42xiFvrdQzafwQsWwwmejfK9-hke6u-35JH7rU5raeF
$** D46lZ2wIgzJYhRIl64btOT+fEIaR0AUCJUq1Rf84F4ybCKyAO-ngJ1JsE1Bq
$** v8h5EWIiDtno8ubPWbWKz-6b8dqqvgzRmgtFUDZJ5ZZsAtpkhGaUpbluIb4V
$** qF5f3fhAtMa4UPphQ4h2tjuFCEZxUhDow8+WDCeT6MgSdXG45YArXsQFyOYC
$** Bui-KGqo2S4GJETw3Nnof0sv3V88OlWYNQ8t0ZaMxPnHPxSedWyyO9AjKTlt
$** Qrdgbrhn3Mlc5yw8X7L
PDMS/E3D will continue to read and process the file as usual (you may test it in your own PDMS/E3D!), but the contents will not be human-readable, and of course, not editable. We have actually incorporated this step into our CI server so we don’t even think about it anymore–just push our code to the repository and Jenkins generates our encrypted and compressed package. Wonderful! But coming back to the topic: why?
First: version consistency. PML is not a compiled language, and all of our subsidiaries would get copies of these files. Most administrators (and even several users) are capable developers. They would take these files and modify them to fit their needs and whims. Normally this is OK–any user should be free to automate their work using the tools they wish–however, it becomes a massive problem once you are working on a Global Project and two locations are expected to use the same version of a PML Application.
If the files are unencrypted and the location admins have changed something critical, it could be a long time before anyone found out that these changes were made and then it is jeopardizing your business. It doesn’t matter that you tell people not to, or that you give them a stern lecture, it is only a matter of time before someone plays with these files and generates a business problem. And now you have an angry project manager breathing down your neck asking you why are you delaying his deliverables.
The Germans say “Trust is good, control is better.” And now I am pro-encryption.
Another good case for encryption is when you are working with third parties. We have several applications in our environment that interface with material management systems, procurement, among others. When a project requires us to outsource some PDMS/E3D modelling, we need to provide these applications to third party companies.
Encryption of course protects the company’s intellectual property, but you can also add safeguards and timed checks to your development. For example, you can check the current banner and ensure the app will only work for your current partner (and nobody will take the code elsewhere!):
!banner = BANNER
!company = !banner.company
if (!company.neq('ThirdPartyCompany')) then
return error
endif
After encryption this check will not be modifiable–so if the third party company shares it to someone else, it will just return an error. It is also possible, with the same approach, to put a time-lock on these files, and prevent them from working after a certain date.
So should you encrypt your PML as soon as it leaves your fingertips? It depends! If you must share important code to your business and you need to ensure that it does not get modified, it could go a long way for you. But remember: no method of encryption or obfuscation is safe, and as already stated, if someone wants to read your code bad enough, they will be able to. Nonetheless, correct use of encryption can improve the security and consistency of your code, which is something that is sadly too often jeopardized in more “informal” developing environments.