Há muito tempo eu aprendi sobre PML Encryption e sempre senti que na maioria das vezes era uma má idéia. Isto vem da experiência e do conhecimento sobre a ofuscação do código: na melhor das hipóteses, é inútil (se alguém realmente quiser ler seu código, será capaz de fazê-lo), e na pior das hipóteses, está prejudicando diretamente a qualidade de seu produto.

Apesar de minhas objeções, descobri que a equipe de administração central da minha empresa o fazia e não liberava o código fonte para nossas aplicações internas de PML. Na verdade, ouvi de alguns de nossos administradores que não gostavam desta prática a ponto de se sentirem insultados com o nível de desconfiança proveniente de nosso escritório central. Até certo ponto eu concordava, e pensava que isso introduzia burocracia desnecessária pra solicitar modificações e correções de bugs nessas aplicações, pois não podíamos inspecioná-las em caso de falha.

Eventualmente me integrei à equipe administrativa na Alemanha e desafiei essa prática. Entretanto, no devido tempo, cheguei a entender porque nossa equipe tomou esta decisão, e porque ela é importante.

Como assim?

Mas antes disso: como funciona a PML Encryption? Bem, digamos que você tenha um arquivo PML. Você precisa obter uma licença da AVEVA para usar a PML Publisher. Tenhamos por exemplo a seguinte função de PML:

define function .thisFunctionIsEncrypted( )
  write 'This function is encrypted.'
endmethod

Executamos:

pmlencrypt "C:\path\thisFunctionIsEncrypted.pmlfnc" "C:\path\encrypted\thisFunctionIsEncrypted.pmlfnc" -rc4

…e voila! Seu arquivo está encriptado.

--<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

O PDMS/E3D continuará a ler e processar o arquivo como de costume (você pode testá-lo em seu próprio PDMS/E3D!), mas o conteúdo não será legível por humanos e, é claro, não será editável. Na verdade, incorporamos esta etapa em nosso servidor CI para que não pensemos mais nisso – basta subir nosso código para o repositório e Jenkins gera nosso pacote criptografado e comprimido. Maravilhoso! Mas voltando ao tema: por quê?

Um pouco de consistência

Primeiro: consistência. PML não é uma linguagem compilada, e todas as nossas subsidiárias recebem cópias destes arquivos. A maioria dos administradores (e até mesmo vários usuários) são programadores capazes. Eles poderiam pegar esses arquivos e modificá-los para atender às suas necessidades. Normalmente isto é perfeitamente OK – qualquer usuário deve ser livre para automatizar seu trabalho usando as ferramentas que desejar – mas, torna-se um enorme problema quando se está trabalhando em um Projeto Global e espera-se que dois locais usem a mesma versão de uma Aplicação PML.

Se os arquivos não estiverem criptografados e os administradores ou usuários do local tiverem mudado algo crítico, pode levar muito tempo até que alguém descubra que estas mudanças foram feitas e, então, isso está prejudicando seu projeto. Não importa que você diga às pessoas para não o fazerem, ou que você lhes dê um belo “deixa-disso”, é apenas uma questão de tempo até que alguém brinque com estes arquivos e gere um problema. E agora você tem um gerente de projeto respirando no seu pescoço perguntando por que você está atrasando o projeto.

Os alemães dizem: “A confiança é boa, o controle é melhor”. E agora eu sou a favor da encriptação.

Compartilhe melhor seu trabalho e durma (um pouco)

Outro ponto a favor da encriptação é quando você está trabalhando com terceiros. Temos várias aplicações em nosso ambiente que fazem interface com sistemas de gerenciamento de materiais, aquisições, entre outros. Quando um projeto exige que terceirizemos alguma modelagem PDMS/E3D, precisamos fornecer essas aplicações para empresas terceirizadas.

A encriptação, é claro, protege a propriedade intelectual da empresa, mas você também pode acrescentar salvaguardas e verificações cronometradas ao seu desenvolvimento. Por exemplo, você pode verificar o banner atual e garantir que o aplicativo só funcionará para seu parceiro atual (e ninguém levará o código para outro lugar!):

!banner = BANNER
!company = !banner.company
if (!company.neq('ThirdPartyCompany')) then
  return error
endif

Após a cifragem, esta verificação não será modificável – portanto, se a empresa terceirizada a compartilhar com outra pessoa, ela simplesmente retornará um erro. Também é possível, com a mesma abordagem, colocar um bloqueio de tempo nestes arquivos, e impedir que eles funcionem após uma determinada data.

Não há balas de prata

Então você deve encriptar seus arquivos PML? Depende! Se você tiver que compartilhar um código importante para seu negócio e precisar garantir que ele não seja modificado, pode ser muito útil. Mas lembre-se: nenhum método de criptografia ou ofuscação é 100% seguro e, como já foi dito, se alguém quiser ler seu código com muito tempo e vontade, será capaz de fazê-lo. No entanto, o uso correto da cifragem pode melhorar a segurança e a consistência de seu código, o que é algo que, infelizmente, muitas vezes é prejudicado em ambientes de desenvolvimento mais “informais”.

Mas como isso afeta a performance? Fique atento a outro artigo!