Como assinar um applet

Como assinar um applet

Fonte: http://insonix.blogspot.com/2009/04/como-assinar-um-applet.html

Se você estiver se perguntando, para que precisa assinar meu applet, ai vai a resposta.
Existem várias questões de segurança envolvendo a chamada de arquivos e aplicações externas de dentro do navegador, e para executar alguma função mais específica, ou até mesmo rodar executáveis do sistema operacional a partir do seu applet, você precisa criar uma assinatura digital para ele.
Até mesmo para identificar que este applet é assinado pela empresa ou site cujo ele está sendo executado.

Vamos ao que interessa.

Como exemplo, eu criei um applet Exemplo.java que gerou o binário Exemplo.class.

1 – Criar um JAR
Criar um JAR com a classe envolvida, pois a assinatura será feita em cima do jar.
Na linha de comando, vá até a pasta em que o .class de sua classe está e digite:

jar cvf Exemplo.jar Exemplo.class

Neste momento foi criado um jar chamado Exemplo.jar.

2 – Criar o par de chaves (chave pública e privada)
Na linha de comando digite:

keytool -genkey -dname “cn=Exemplo, ou=Laboratorio, o=Empresa, c=BR” -alias exemplo -storepass 123456 -validity 3655

Detalhes do comando

-dname = dados da organização/empresa/site
-alias = nome da chave criada, no caso “exemplo”
-storepass = pass da chave, quando for assinar um jar com esta chave por exemplo, será necessário digitar este pass
– validity = quantidade de dias de validade da assinatura digital

Esta chave fica guardada na pasta home do usuário, e você poderá utilizar apenas o alias dela quando for assinar o JAR.

3 – Assinar o JAR do applet
Assinar o JAR do applet, criado no passo 1.

Na linha de comando digite:

jarsigner -storepass 123456 Exemplo.jar exemplo

Detalhes do comando

-storepass = pass da chave, conforme explicado no passo 2
Exemplo.jar = arquivo jar criado no passo 1
exemplo = alias da chave, criada no passo 2.

Pronto, é só jogar o seu JAR para sua aplicação, e agora caso você em seu applet, chamava um .class, é só chamar o .JAR.

Seu applet já está assinado.

Anúncios

Bugtracker – Como é possível não usar?

Fonte: http://inospito.com/2007/11/01/bugtracker-como-e-possivel-nao-usar/

Uma das ferramentas básicas para o desenvolvimento de software com qualidade é o bugtracker. Tal como um bom IDE, o bugtracker é uma das ferramentas das quais não prescindo de maneira nenhuma, e considero a sua utilização como um requisito obrigatório se queremos desenvolver software com qualidade.

Infelizmente, os cursos de Engenharia Informática em Portugal não abordam este assunto, pelo que (já) não me surpreende que tenha encontrado tantos programadores ao longo dos anos que não usam nem fazem ideia da sua utilidade. Para quem não sabe, um bugtracker é simplesmente uma ferramenta onde se introduzem os bugs que encontramos numa aplicação e onde podemos depois acompanhar e controlar a evolução de cada bug: se está a ser corrigido, se já foi corrigido, em que versão foi corrigido, etc. Claro que as ferramentas de bugtracking fazem uma miríade de outras coisas, como relatórios, envio de mails de notificação ou pesquisas, mas o que realmente interessa é permitir acompanhar/controlar a evolução de um bug. Como é que uma ferramenta tão simples pode ter um papel tão importante?

Quando não usamos um bugtracker, temos o seguinte possível cenário (imaginem dois developers X e Y):

  1. X recebe um telefonema de um cliente, desesperado com um comportamento estranho da aplicação quando se clica duas vezes no quadrado vermelho que pisca
  2. X já imagina qual a linha de código que estragou a coisa e começa a corrigir
  3. Y que não está junto de X, recebe um telefonema de outro cliente com o mesmo problema. Claro que nós (leitores) sabemos que é o mesmo problema, mas o cliente não sabe e muito menos Y. Ainda por cima, Y nem imagina onde esteja o bug, porque ele não desenvolveu essa parte da aplicação.
  4. Y começa a tentar descobrir onde está o bug
  5. X já quase resolveu o bug, mas está a demorar imenso tempo porque está permanentemente a ser interrompido por telefones e mails de clientes a refilar por causa do bug.
  6. X resolve o bug e faz uma nova versão da aplicação. Claro que a nova versão não tem só a correcção do quadrado vermelho que pisca. Tem outras correcções que foram feitas recentemente. Ele tem que compilar a lista de correcções: ver os mails trocados entre os developers, telefonar aos outros developers, etc.
  7. Y já encontrou o sítio onde está o bug mas entretanto recebe um telefonema de X, perguntando que correcções foram feitas recentemente. Y diz-lhe que está a resolver o problema do quadrado vermelho que pisca. X responde-lhe que já foi resolvido. Y desespera. Os clientes continuam a telefonar.

Se usassem um bugtracker, o cenário poderia ser algo diferente:

  1. X recebe um telefonema de um cliente, desesperado com um comportamento estranho da aplicação quando se clica duas vezes no quadrado vermelho que pisca
  2. X introduz no bugtracker a descrição do bug e comunica ao cliente o identificador do bug, para que o cliente possa acompanhar a evolução do mesmo através da web (outra hipótese seria o próprio cliente introduzir o bug no bugtracker).
  3. X já imagina qual a linha de código que estragou a coisa e começa a corrigir, mas primeiro marca esse bug como “Em Correcção” na ferramenta
  4. Y que não está junto de X, recebe um telefonema de outro cliente com o mesmo problema. Claro que nós (leitores) sabemos que é o mesmo problema e Y, após pesquisar no bugtracker, também sabe.
  5. X resolveu o bug rapidamente porque a maioria dos clientes, antes de telefonarem ou enviarem email a refilar, pesquisaram no bugtracker e viram que o bug estava em correcção.
  6. X faz uma nova versão da aplicação e consegue saber todas as correcções incluídas na versão com uma simples pesquisa “Bugs resolvidos na versão XXX”

Existem imensos bugtrackers no mercado, muitos deles open-source. E não existe razão nenhuma para não se usar um bugtracker. Claro que podemos usá-los de muitas formas, algumas mais correctas do que outra. Espero falar disso num futuro post. Mas uma coisa vos garanto. Quem já trabalhou com um bugtracker, nem se imagina a trabalhar um dia sem um.