Como vocês lidam com a proteção do código em python?

[Fellipe Henrique]

Amigos,

Como vocês lidam com a proteção do código em python? Digo, claro que teremos contrato e tals, mas nada impede alguém de pegar o código e fazer alguma coisa.

Então, além de ter o contrato e tals, o que posso fazer para proteger o código?

T.·.F.·.A.·.     S+F

Fellipe Henrique P. Soares

Blog: http://fhbash.wordpress.com/

GitHub: https://github.com/fellipeh

Twitter: @fh_bash

[Tito Gonzales]

Acho que é só o contrato mesmo, se alguém usar parte de seu codigo esta sujeito a processo.

[Fellipe Henrique]

Certo, mas isso não é garantia, visto como é a nossa justiça, então, além do contrato queria ver algo a mais pra proteger, pra caso venha a ter problemas, eles sejam mínimos.

Abs

Em segunda-feira, 13 de janeiro de 2014, Tito Gonzales escreveu:

Acho que é só o contrato mesmo, se alguém usar parte de seu codigo esta sujeito a processo.

--
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar

<*> Para visitar o site do grupo na web, acesse:
    http://groups.google.com/group/python-brasil

<*> Para sair deste grupo, envie um e-mail para:
    python-brasi...@googlegroups.com

---
Você está recebendo esta mensagem porque se inscreveu no grupo "Python Brasil" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para python-brasi...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

--
Sent from my iPhone

[Bruno Rocha]

DEpendendo do framework/lib você pode compilar e fazer deploy apenas dos arquivos .pyc

2014/1/13 Fellipe Henrique <fell...@gmail.com>

--

Bruno Rocha - @rochacbruno

http://github.com/rochacbruno

http://brunorocha.org

http://pythonhub.com

[Joao S. O. Bueno]

2014/1/13 Fellipe Henrique <fell...@gmail.com>:

> Certo, mas isso não é garantia, visto como é a nossa justiça, então, além do
> contrato queria ver algo a mais pra proteger, pra caso venha a ter
> problemas, eles sejam mínimos.
>

Essa é a única garantia que você tem.
E essa é a forma normal de lidar com esse assunto em Python:
você deixa o código fonte onde o programa precisa rodar.

Há comod eixar só os arquivos em bytecode, há formas de
obfuscar o programa, há formas de baixar bytecode assinado sob demanda
em tempo de execução - e tudo o que isso vai fazer é: proteger o seu
código de quem _não_ tem interesse em ganhar alguma coisa maquiando o
seu código e o revendendo de forma pirata.

Por que se a pessoa for ganhar com isso, ou, se houver por exemplo,
questões de segurança envolvidas, nenhuma das formas que mencionei
acima é garantia de que vai parar quem está mal-intencionado. E nesse
caso, quem está no mato sem cachorro é você: uma vez que optou por
segurança por obscuridade, qualquer caminho judicial que vá tomar vai
ser mais lento, e vai ter que explicitar seu código de qualquer jeito
no processo, para provar que a pessoa está infringindo o seu direito
de autor.

( Por outro lado, pode até ser que a pessoa "sabendo que você sabe"
que ela pode ver o código fonte, vai pensar duas vezes antes de
colocar no mercado um produto com código derivado do mesmo)

E -- pior, imagine esse cenário: você mantém seu codigo trancado no
seu ambiente a sete chaves e entrega só uma cópia obfuscada do produto
ao seu cliente. Esse eventualmente encontra uma forma de desobfuscar o
código (e sempre vai ter uma: o código tem que estar "desobfuscado"
para poder rodar), e pública grande parte do seu código na internet,
como se fosse dele mesmo. Como é que você vai provar que o original é
seu?? Com cópias do código que estão no seu HD, sendo que um um
simples script pode colocar a data que quiser em qualquer arquivo?
Claro, você vai ter os logs do controle de versão da sua equipe, mas
para isso passar de "forte evidência" para "prova" é um caminho longo.

Essa questão não é algo específico do Python: o problema de uma pessoa
mal-intencionada
poder descompilar um programa em qualquer linguagem. Em Python, a
pequena dificuldade técnica de se i entregar um arquivo ".exe" para o
cliente e achar que assim está "protegendo o código", na verdade vem
ao encontro da filosofia da linguagem : ao implementar algo, faça bem
feito, ou não faça nada - mas não faça algo que "só funciona as vezes"
e fique achando que fez.


Isso ficando bem claro, há sim formas de obfuscar o código - vamos ver
o que o pessoal
tráz de idéias aí.

js
-><-

[Alexandre Dias]

Esse assunto é complexo, alguns dizem que não devemos proteger de jeito nenhum, outros dizem que devemos trancar, meu ponto de vista é bem simples, eu usei o py2exe algumas vezes quando quis evitar somente que o usuário "curioso" bisbilhotasse certos locais do código, claro que um usuário mais avançado poderia utilizar de técnicas mais avançadas pra tentar descompilar, mas o objetivo não era esse, era só não deixar tão exposto. Quem trabalha com apps para desktop sabe do que estou falando, se vc deixa o código exposto, seu usuário pode ter acesso a certas funções que não deveria, então vamos por níveis, eu concordo com todos! Concordo com os que querem passar o fonte pra frente, concordo com os que querem esconder um pouco do seu código pra não deixar tão exposto, e também concordo com os que querem um criptografar o código com um complexo algoritmo de 2048 bits pq acham que com sua genialidade desenvolveram o melhor algoritmo do mundo, e que os outros meros mortais não devem conhecer (brincadeiras a parte, também concordo com esses). A questão é eu uso o py2exe, ele não esconde muito, mas é o suficiente pra meu usuário não ficar futucando aonde não deve.

Alexandre Lourenço Dias
IT Manager
+55 71 9134-1759

[Paulo Patto]

Distribua o software como SaaS então. Por mim se o cara revendesse meu código eu até. Ia gostar, tipo Microsoft, até uma hora que eu cobro do pirata em indenização e fico com o cliente pseudo acostumado a meu software. Simples.

[Fellipe Henrique]

Bom, eu concordo com todos, tenho códigos abertos, e alguns fechados. Tudo depende do projeto. O projeto em questão será desenvolvido em django, e deverá obrigatoriamente ficar no servidor do cliente. Vou ter acesso ao servidor, porém o servidor é da empresa e ela pode fazer o que quiser. Por exemplo, ela pode simplesmente fechar o servidor, contratar outra empresa e "dar" o código para ela continuar. Certo que tem contrato e tals, mas o tempo de um processo, custo e tals gira em mais de 5 anos, no mínimo. E o pior, o estrago já foi feito e dificilmente será recuperado.

[]s

T.·.F.·.A.·.     S+F

Fellipe Henrique P. Soares

Blog: http://fhbash.wordpress.com/

GitHub: https://github.com/fellipeh

Twitter: @fh_bash

[Eduardo Oliva]

Bom, infelizmente, não tem muito como vc ofuscar o código, principalmente se o cliente tiver acesso físico à máquina.

A idéia do Paulo acima, na minha opinião é a melhor, ou seja, deixar o software em cloud,  pois assim o cliente não teria acesso.

Agora caso seja obrigatório o uso de um servidor interno no cliente, creio que vc possa oferecer seu projeto como um Appliance, vc será o responsável pelo software juntamente com o hardware, e protegidos por contrato.

Sinceramente, reverter bytecode em código fonte é uma coisa relativamente simples, no final de tudo, o computador só vai entender código de máquina, e descompilar isso eh tranquilo.

Mais uma opção seria você pegar as partes mais inteligentes do seu código, e escrever em C, compilar e chamar pelo Python...também funciona, mas como te disse, um cara que manjar de engenharia reversa e tiver acesso ao servidor, descompila isso fácil, principalmente no linux, onde um objdump já te dá quase tudo que precisa :)

É isso meu querido!!

Eduardo Oliva

[Paulo Patto]

Sério, se o cliente compro o software de você o código é dele não? E mesmo assim, o contrato de não distribuição deve ser bem "xudido!" para o caso do caro pirateie. 

Mas uma coisa, que não me desce, o pessoal fala tanto em proteger o código mas se olhar bem, quantos aqui tem a capacidade de modificar drasticamente um PostgreSQL ao ponto de falar que é um software seu e mesmo assim o código fonte está ai todinho na internet... 

2014/1/14 Eduardo Oliva <dut...@gmail.com>

--

Paulo Patto

"Se em vez de enchermos o bolso enchermos a cabeça, não seremos roubados"

[Filipe Cifali]

Acho que nem chega a esse ponto Paulo, é acreditar no profissionalismo alheio.

A idéia toda é proteger o desenvolvedor. Depende do que ele estiver vendendo, se é o serviço, se é o código, se são as horas trabalhadas.

Se o cliente pagou pelo código, crie, entregue e se abstenha da responsabilidade de "pai" do código. O código não é seu, a lógica não é sua, é propriedade da empresa.

Se eles te pagaram pelo serviço, é diferente e a aproximação de você deixar o serviço rodando no servidor deles implicita outras coisas como suporte e monitoramento.

2014/1/14 Paulo Patto <paulo...@gmail.com>

--
[ ]'s

Filipe Cifali Stangler

[Maxwell Oliveira]

Vou dar meus 20cents;

 ** Problemas ** 

Sistema em Cloud    : Se você vendo um sistema, não pode obrigar ao cliente a utilizar uma infra estrutura sua. Ai é ele quem pode te processar por venda casada;

Sistema com codigo aberto : O mundo é promiscuo e 100% das vezes o usuário vai utilizar o seu codigo seja para dar manutenção e/ou procurar algum meio mais barato copiar/ vender/ utilizar em outro local.... etc.

Direito Autoral : na visão juridica é um processo "simples", MAS , antes deste processo tem a parte de identificação do usuário não autorizado ai é onde se perte tempo e dinheiro pois tudo tem que ser feito com avão juridico e pode demorar anos.

[Paulo Patto]

Mas é direito do cara, ele buscar outra manutenção mais barata... Ora pois nem todo mundo vai ficar fazendo manutenção na autorizada da montadora sempre, pois haja grana. E as vezes o trampo do "Wilson - Mecânico"  do bairro resolve o seu problema em muitos casos. Agora um cenário que se eu entendi bem de monitoramento, onde você desenvolve uma ferramenta para ficar no cliente... bem ai vai de licensa de uso e coisas do tipo. Eu trabalhava com um software do CPqD no qual tinhamos de usar um pendrive como token de licensa que espirava de tempos em tempos.

mas como descrito acho que o aplicativo vai ser em Django e provavelmente vai ser um sistema do cliente e não uma ferramenta utilitária do DEV. 

2014/1/14 Maxwell Oliveira <max...@gmail.com>

--

[Rodrigo 'Skhaz' Delduca]

Algumas pessoas estão confundindo segurança com ofuscação, onde uma coisa não tem nada a ver com a outra, mas um código ofuscado pode aumentar significamente a segurança, mas o bug, a falha de segurança em si não será "removida" aplicando esse método.

Supondo que seu código deve rodar localmente por N motivos, *eu* faria da seguinte forma:

Escreveria todo o código que é critico em C, ou melhor, em C++ usando e abusando de metaprogramming com templates[1] e aplicando diversas técnicas de ofuscação[2]; Existe um livro muito bom sobre o assunto, do qual não me recordo o nome agora.

Após isso, exportaria esse código usando o boost.python, assim, seria possível importar diretamente no python e usar. Isso não é uma bala de prata, mas sem dúvida nenhuma é melhor do que distribuir os .pyc, Python é uma linguagem muito bem documentada e open-source, por esses motivos é muito fácil aplicar técnicas de engenharia reversa. Já um código em C++ usando MPL e ofuscação fica um pouco mais complicado.

Att.

1 - http://www.boost.org/doc/libs/1_55_0/libs/mpl/doc/index.html

2 - http://en.wikipedia.org/wiki/Obfuscation_(software)

2014/1/14 Paulo Patto <paulo...@gmail.com>

--
http://www.nullonerror.org/
-- flipping bits whilst updating pixels

"""They say hackers die twice, once when they pass, and then again when the last of their code is rewritten by some asshole using JavaScript"""

[Andre Luis]

Minha opinião sobre o assunto é simples ..... código aberto .... não importa se alguém copiar, alterar, melhorar (ou piorar) o programa .... cobra-se pelo seu conhecimento aplicado para construir o sistema e o que será feito no futuro não importa .... se vender o serviço (desenvolvimento) ao invés do sistema você não terá que se preocupar com isso.

"technology does not drive change - it enables change"

[Élysson Mendes Rezende]

Vou compartilhar o que eu penso sobre isso e um pouco de experiência que eu já adquiri ao longo do tempo.

Eu acho que quem se preocupa em proteger ("fechar") o código é porque não esta seguro do próprio trabalho. Se você fez algo realmente bom, o seu cliente não vai procurar alguém que faça mais barato, ele vai te procurar. Você já conhece o sistema desenvolvido, você já tem o seu trabalho comprovado, ele já conhece os seus prazos, ou seja, ele conhece o seu trabalho e sabe que você vai entregar algo com qualidade. Ninguém vai trocar o certo pelo duvidoso.

Eu estava conversando com um amigo da pós a respeito disso, ele concordou comigo mas na prática ele disse que não é bem assim, ai eu falei para ele que esses caras não são bons clientes ou o sistema é muito simples, dai neste caso não tem como cobrar um preço justo porque com certeza o cliente sempre vai buscar o melhor preço. Num sistema simples qualquer pessoa pode (em tese) dar manutenção, algo mais complexo o cliente não vai chamar qualquer um por conta do preço, o barato pode sair caro.

2014/1/14 Andre Luis <alpb...@gmail.com>

--

Élysson MR
Talk/Email: elys...@gmail.com
Skype:       elyssonmr
Twitter:       @elyssonmr

LinkedIn:    http://br.linkedin.com/in/elyssonmr/

Github:       https://github.com/elyssonmr

[Fellipe Henrique]

Olá meus amigos, estou gostando da conversa, e concordo com grande parte com o que os amigos disseram, principalmente o que o Rodrigo disse.

Em 14 de janeiro de 2014 14:48, Élysson Mendes Rezende <elys...@gmail.com> escreveu:

Eu acho que quem se preocupa em proteger ("fechar") o código é porque não esta seguro do próprio trabalho

Discordo plenamente com essa sua afirmativa! proteção de código, ou proteção de propriedade intelectual, não quer dizer que o trabalho está em xeque. Apenas que a empresa que desenvolveu quer proteger o que foi gasto durante o processo.

Existem vários tipos de projetos, open-source, totalmente fechado, parcialmente fechado e etc.. e se o cliente somente aluga o sistema e requer que seja usado o servidor deles, a empresa em questão deve procurar alguma forma de proteger a propriedade do código, não importando o motivo, e é este ponto que eu estou levantando. Não o motivo, apenas o que se pode fazer.

[Élysson Mendes Rezende]

Fellipe, eu pensei na minha afirmativa quando o cliente estivesse solicitado um projeto para ele. A deia é de ter um produto e instala-lo nos clientes ou é a ideia que eu pensei mesmo?

Abraço

2014/1/14 Fellipe Henrique <fell...@gmail.com>

--

--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
 
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
 
<*> Para sair deste grupo, envie um e-mail para:
python-brasi...@googlegroups.com
 
---
Você está recebendo esta mensagem porque se inscreveu no grupo "Python Brasil" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para python-brasi...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

[Fellipe Henrique]

O idéia é que o produto já existe, mas por força de política da empresa, se faz necessário ser instalado no servidor da empresa.

[]s

T.·.F.·.A.·.     S+F

Fellipe Henrique P. Soares

Blog: http://fhbash.wordpress.com/

GitHub: https://github.com/fellipeh

Twitter: @fh_bash

[Tito Gonzales]

Felipe, ficou interessante a thread que vc iniciou.

Na minha opinião não se trata de proteção de código, mas sim de negociação comercial. Vender um software dependendo que o cliente fique atrelado a você com a manutenção do mesmo, é sinal de orçamento mau dimensionado. O custo do software é um e manutenção é outro, se o software já está desenvolvido e seu cliente quer a fonte dele, é a mesma questão, vc deve vender os direitos pra ele. 

[Paulo Patto]

Uma pergunta ainda na mesma linha, até onde eu sei software como o enterprise.github.com não é ofuscado e é vendido de boa. Assim como o GitLabHQ (ok é opensource), Confluence, Jira, etc. quem aqui vê algum vendendo esses softwares por ai? Todos com código até onde eu saiba a disposição do cliente.

2014/1/14 Tito Gonzales <produtoram...@gmail.com>

--

[Fellipe Henrique]

Em 14 de janeiro de 2014 17:18, Tito Gonzales <produtoram...@gmail.com> escreveu:

se o software já está desenvolvido e seu cliente quer a fonte dele

A questão é que o cliente não quer os fontes, mas eles estarão lá no servidor deles..essa é a questão.

[Kayro]

Eu tinha um sistema de contabilidade pública que as DLL's levavam singelos nomes de astros do sistema solar (no intuito de ofuscar a lógica por trás da aplicação)... Por fim acabou ficando engraçado, os caras me ligavam dizendo que deu pau na Lua, pegou fogo no sol e trocadilhos do tipo rs...

[Douglas Camata]

Eu acho que proteção de código é uma coisa inútil. Se no contrato está definido que o software é do cliente, se eu fosse cliente, iria exigir acesso e controle total sobre ele e inclusive a possibilidade de quebrar o contrato com você e chamar outros para continuar o software. Agora, se no contrato diz que o cliente não é o dono do software e que mesmo assim o software deve ficar no servidor dele, há uma grande falha ai.

Além de praticamente todo o tipo de proteção de código em Python se reversível, a não ser que você criptografe, com RSA, por exemplo, ou coisas do tipo, devido a existência do bytecode. 

2014/1/15 Kayro <tagg...@gmail.com>

--
Douglas Camata
Graduando em Ciência da Computação (UENF)

Blog: http://douglascamata.net

Github: http://github.com/douglascamata

Twitter: @douglascamata

Skype: douglas_camata

-----------------------------------
Linux User #509211