Hace mucho tiempo que conozco el Cifrado de PML, y siempre había pensado que la mayoría de las veces es una mala idea. Esto viene de la experiencia y el conocimiento sobre la ofuscación de código: en el mejor de los casos es inútil (si alguien realmente quiere leer tu código, podrá hacerlo), y en el peor de los casos está perjudicando directamente la calidad de tu producto.
A pesar de mis objeciones, descubrí que el equipo de administración central de mi empresa utilizaba Cifrado de PML y no liberaba el código fuente de nuestras aplicaciones internas de PML. De hecho, escuché a algunos de nuestros administradores de las filiales que no les gustaba esta práctica hasta el punto de sentirse insultados por el nivel de desconfianza de nuestra oficina central. Hasta cierto punto estaba de acuerdo, y pensaba que introducía una burocracia innecesaria a la hora de solicitar modificaciones y correcciones de errores en estas aplicaciones, ya que no podíamos revisarlas en caso de fallo.
Con el tiempo, me incorporé al equipo de administración y cuestioné esta práctica. Sin embargo, con el tiempo llegué a entender por qué nuestro equipo tomó esta decisión, y por qué es importante.
Pero antes de eso: ¿cómo funciona el cifrado PML? Bien, digamos que tienes un bonito archivo PML. Necesitas obtener una licencia de AVEVA para utilizar PML Publisher. Tengamos una función PML:
define function .thisFunctionIsEncrypted( )
write 'This function is encrypted.'
endmethod
Ejecutas un comando:
pmlencrypt "C:\path\thisFunctionIsEncrypted.pmlfnc" "C:\path\encrypted\thisFunctionIsEncrypted.pmlfnc" -rc4
…y voila! Tu archivo estará cifrado.
--<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 continuará leyendo y procesando el archivo como de costumbre (¡puedes probarlo en tu propio PDMS/E3D!), pero el contenido no será legible para los humanos, y por supuesto, no será editable. De hecho, hemos incorporado este paso en nuestro servidor de CI, de modo que ya ni siquiera pensamos en ello: simplemente subimos nuestro código al repositorio y Jenkins genera nuestro paquete cifrado y comprimido. Es una maravilla. Pero volviendo al tema: ¿por qué?
Primero: consistencia. PML no es un lenguaje compilado, y todas nuestras filiales obtendrían copias de estos archivos. La mayoría de los administradores (e incluso varios usuarios) son desarrolladores capaces. Tomarían estos archivos y los modificarían para adaptarlos a sus necesidades y caprichos. Normalmente esto está bien -cualquier usuario debería ser libre de automatizar su trabajo utilizando las herramientas que desee- pero se convierte en un problema enorme cuando se trabaja en un proyecto global y se espera que dos ubicaciones utilicen la misma versión de una aplicación PML.
Si los archivos no están cifrados y los administradores de la ubicación han cambiado algo crítico, podría pasar mucho tiempo antes de que alguien descubra que estos cambios se hicieron y entonces el proyecto está en riesgo. No importa que le digas a la gente que no lo haga, o que les des un severo sermón, es sólo cuestión de tiempo que alguien juegue con estos archivos y genere un problema. Y ahora tienes a un PM enfadado respirando en tu nuca preguntándote por qué estás retrasando sus entregables.
Los alemanes dicen “La confianza es buena, el control es mejor”. Y ahora estoy a favor de cifrar.
Otro buen punto a favor para cifrar es cuando trabajas con terceros. Tenemos varias aplicaciones en nuestro entorno que interactúan con los sistemas de gestión de materiales, compras, entre otros. Cuando un proyecto requiere que subcontratemos algunos modelos PDMS/E3D, tenemos que proporcionar estas aplicaciones a terceras empresas.
El cifrado, por supuesto, protege la propiedad intelectual de la empresa, pero también se pueden añadir salvaguardas y comprobaciones temporales al desarrollo. Por ejemplo, puedes comprobar el banner actual y asegurarte de que la aplicación sólo funcionará para tu socio actual (¡y nadie se llevará el código a otra parte!):
!banner = BANNER
!company = !banner.company
if (!company.neq('ThirdPartyCompany')) then
return error
endif
Después de cifrar, esta comprobación no será modificable, por lo que si la tercera empresa la comparte con otra, simplemente devolverá un error. También es posible, con el mismo enfoque, poner un bloqueo de tiempo en estos archivos, y evitar que funcionen después de una fecha determinada.
Entonces, ¿deberías cifrar tu PML tan pronto como salga de tus manos? Depende. Si tienes que compartir un código importante para tu empresa y necesitas asegurarte de que no se modifique, te puede venir muy bien. Pero recuerde: ningún método de cifrado u ofuscación es 100% seguro y, como ya se ha dicho, si alguien realmente quiere leer tu código, podrá hacerlo. No obstante, el uso correcto del cifrado puede mejorar la seguridad y la consistencia de tu código, algo que lamentablemente se pone en peligro con demasiada frecuencia en los entornos de desarrollo más “informales”.