Mudanças entre as edições de "Ata da 43a"

De PJe
Ir para: navegação, pesquisa
(Local)
(Pauta)
Linha 63: Linha 63:
 
- a plataforma Java em cliente é executada em um plugin do navegador (o Java Plugin), instalado pelos usuários por meio do Java Runtime Environment. Esse plugin é atualizado com periodicidade aproximadamente trimestral por sua fabricante (Oracle Corp.), mas podem e têm havido liberações ou atualizações em intervalos menores de tempo em razão da constatação de vulnerabilidades graves exploradas por hackers. Mais que isso, toda a política de segurança na execução de mini-aplicativos java em navegadores foi modificada no ano de 2013.  
 
- a plataforma Java em cliente é executada em um plugin do navegador (o Java Plugin), instalado pelos usuários por meio do Java Runtime Environment. Esse plugin é atualizado com periodicidade aproximadamente trimestral por sua fabricante (Oracle Corp.), mas podem e têm havido liberações ou atualizações em intervalos menores de tempo em razão da constatação de vulnerabilidades graves exploradas por hackers. Mais que isso, toda a política de segurança na execução de mini-aplicativos java em navegadores foi modificada no ano de 2013.  
 
- no PJe, é necessária a utilização dessa plataforma java para a realização da autenticação do usuário e de suas assinaturas digitais nos documentos, uma vez que ainda não há um padrão tecnológico que permita utilizar funções dos navegadores para acessar o dispositivo criptográfico de modo a realizar essas funções. No ano de 2013, em razão das sucessivas modificações de política de segurança do JRE nos navegadores - algumas delas contraditórias entre si -, tivemos que liberar três versões diferentes da applet durante o ano, a última delas no dia 08/11/2013. Essa última versão da applet (1.0.8) é aderente à todas às políticas da versão 1.7.0_45 do JRE, tendo sido mantidas as políticas na versão lançada no dia 14 próximo passado (1.7.0_51). Após a liberação da versão 1.0.8, foram lançadas novas versões do PJe contendo a nova applet nas famílias 1.4.6.x, 1.4.7.x, 1.5.x e 1.6.x.
 
- no PJe, é necessária a utilização dessa plataforma java para a realização da autenticação do usuário e de suas assinaturas digitais nos documentos, uma vez que ainda não há um padrão tecnológico que permita utilizar funções dos navegadores para acessar o dispositivo criptográfico de modo a realizar essas funções. No ano de 2013, em razão das sucessivas modificações de política de segurança do JRE nos navegadores - algumas delas contraditórias entre si -, tivemos que liberar três versões diferentes da applet durante o ano, a última delas no dia 08/11/2013. Essa última versão da applet (1.0.8) é aderente à todas às políticas da versão 1.7.0_45 do JRE, tendo sido mantidas as políticas na versão lançada no dia 14 próximo passado (1.7.0_51). Após a liberação da versão 1.0.8, foram lançadas novas versões do PJe contendo a nova applet nas famílias 1.4.6.x, 1.4.7.x, 1.5.x e 1.6.x.
- a atualização da versão do JRE no dia 14/01/2013 em *nada impacta* os usuários desde que o tribunal esteja utilizando a versão de produção mais moderna do PJe e o usuário mantenha seu computador atualizado;
+
- a atualização da versão do JRE no dia 14/01/2013 em *nada impacta* os usuários, desde que o tribunal esteja utilizando a versão de produção mais moderna do PJe e o usuário mantenha seu computador atualizado;
 
- embora tenhamos estimativas de lançamento das próximas versões do Java (a próxima é em 14/04/2014, com expiração da versão atual em 15/04/2014), nada impede que a Oracle Corp. lance versões em intervalos mais curtos ou mesmo que a política de segurança dos navegadores também seja modificada. Temos nos esforçado para acompanhar essas mudanças e continuaremos assim. Estamos estabelecendo uma política de comunicação social de modo a alertar quanto à necessidade de atualizar seu computador nas proximidades das datas prováveis de atualizações.
 
- embora tenhamos estimativas de lançamento das próximas versões do Java (a próxima é em 14/04/2014, com expiração da versão atual em 15/04/2014), nada impede que a Oracle Corp. lance versões em intervalos mais curtos ou mesmo que a política de segurança dos navegadores também seja modificada. Temos nos esforçado para acompanhar essas mudanças e continuaremos assim. Estamos estabelecendo uma política de comunicação social de modo a alertar quanto à necessidade de atualizar seu computador nas proximidades das datas prováveis de atualizações.
 
- solicitamos que os tribunais mantenham seus PJes atualizados, o que, esperamos, será mais fácil agora que a Resolução 185 foi aprovada.
 
- solicitamos que os tribunais mantenham seus PJes atualizados, o que, esperamos, será mais fácil agora que a Resolução 185 foi aprovada.
 
- no que toca à eventual supressão do uso de mini-aplicativo java para assinatura, têm sido pesquisadas alternativas de soluções que tornem a assinatura digital independente do uso de plugins, mas é necessário, para isso, que haja a consolidação e aprovação definitiva de um padrão Web a respeito, o que está em discussão na W3C e cuja conclusão está prevista para 2015.
 
- no que toca à eventual supressão do uso de mini-aplicativo java para assinatura, têm sido pesquisadas alternativas de soluções que tornem a assinatura digital independente do uso de plugins, mas é necessário, para isso, que haja a consolidação e aprovação definitiva de um padrão Web a respeito, o que está em discussão na W3C e cuja conclusão está prevista para 2015.
 +
Em síntese, foi observado o seguinte cronograma pela Gerência do Projeto:
 +
 +
Em 13.01.2013, a versão 1.7.0_u10 do JRE informou que em versão futura, àquela época ainda indefinida, seria exigida assinatura confiável das aplicações em linguagem Java.
 +
 +
Em 11.11.2013, a aplicação de assinatura para autenticação de usuários no PJe foi lançada com assinatura digital válida do CNJ, com ajustes prevenindo as modificações anteriormente anunciadas no JRE e até aquele momento não postas em prática.
 +
 +
Em 14.01.2014, a versão 1.7.0_u51 do JRE foi lançada, a fim de solucionar, principalmente, três falhas de segurança e finalmente implementar a exigência divulgada em 13.01.2013. Não foi necessária modificação na aplicação do PJe, que tem assinatura digital confiável do CNJ desde 11.11.2013, bastando a atualização do Java JRE no computador do usuário.
 +
 +
Em 15.01.2014, a gerência técnica do PJe emitiu avisos aos tribunais, solicitando que divulgassem a seus usuários a necessidade de atualizarem o software Java JRE em seus equipamentos, e encaminhou passo-a-passo aos representantes das entidades parceiras que integram o comitê gestor do PJe (OAB, Ministério Público, AGU, Defensorias etc.), permitindo ampla divulgação.
 +
  
 
<<< Discussões de deliberações sobre o ponto 1 >>>
 
<<< Discussões de deliberações sobre o ponto 1 >>>
 +
  
 
2. Compartilhar o sistema PJe com a Secretaria de Direitos Humanos.
 
2. Compartilhar o sistema PJe com a Secretaria de Direitos Humanos.

Edição das 09h28min de 24 de janeiro de 2014

Minuta

Conteúdo

Data

24.01.2014

Horário

13h00

Local

Videoconferência / Sala de Reuniões da Presidência - CNJ

Nome Órgão e-mail Presente
Paulo Cristovão de Araújo Silva Filho CNJ paulo.cristovao@cnj.jus.br SIM/NÃO
Eduardo Lang AGU eduardo.lang@agu.gov.br SIM/NÃO
Miguel Ramos CFOAB ramosm@vetorial.net (suplente) SIM/NÃO
Paulo José Rocha Júnior CNMP paulorocha@prdf.mpf.gov.br SIM/NÃO
Marcelo Mesquita Silva JE (TJPI) mmesquit76@gmail.com SIM/NÂO
Helena Elias Pinto JF (TRF-2) helena@jfrj.jus.br SIM/NÃO
Paulo Sérgio Domingues JF (TRF-3) psdoming@jfsp.jus.br SIM/NÃO
Daniela de Freitas Marques JME (TJM-MG) daniela@jmemg.jus.br AUSENTE
Ricardo Antonio Mohallem JT (TRT-3) ricardo.mohallem@tst.jus.br SIM/NÃO
José Hortêncio Júnior JT (TRT-23) jose.hortencio@tst.jus.br AUSENTE
Wilson Almeida Benevides TJMG wilsonbenevides@tjmg.jus.br SIM/NÃO

Questões preliminares

O representante do Conselho Federal da Ordem dos Advogados do Brasil informou a impossibilidade de seu comparecimento na presente reunião quando da solicitação da inclusão do primeiro ponto da pauta (bloqueio do aplicativo de assinatura do PJe em razão de atualização do Java Runtime Environment), tendo solicitado o adiamento da 43ª reunião. Em razão da antiguidade da designação (ocorrida em 08/11/2013), da proximidade desta reunião (menos de uma semana) e do fato de que a data anterior desta 43ª reunião já ter sido adiada, o coordenador não chegou a submeter o pedido de adiamento ao comitê-gestor. Confirmada a pauta na data de ontem, o representante da OAB reiterou a impossibilidade de comparecimento, tendo solicitado cópia da gravação da reunião, momento em que foi informado que as reuniões não seriam mais gravadas por determinação da Secretaria-Geral. À vista da informação, o representante da OAB enviou mensagem à lista afirmando que a marcação da reunião com menos de 24 horas de antecedência demonstraria falta de razoabilidade e levava à conclusão de que esta coordenação teria persistido em realizar a reunião com o objetivo de discutir o ponto 1 sem a presença de representante da OAB. Solicitou, em razão disso, que:

a. as reuniões sejam marcadas com um "prazo razoável mínimo de forma a que todo e qualquer membro do Comitê tenha condições de participar"; b. que o ponto 1 da pauta seja rediscutido na próxima reunião do comitê-gestor.

Submete-se o ponto "a" para discussão, tendo o coordenador informado acreditar que a antecedência que vinha sendo respeitada para a designação das datas de reunião do comitê (dois meses ou duas reuniões) seria razoável para a participação dos membros do comitê, o que não impede que se estabeleça um prazo limite para o fechamento da pauta em substituição à solicitação do representante da OAB ou mesmo que se delibere por um prazo mínimo no momento, com nova discussão na próxima reunião de que o representante participar.

<<< Discussões e deliberações sobre o ponto "a" >>>

Submete-se o ponto "b" para discussão, tendo o coordenador apontado ser necessário que se esclareça e, em especial, que se registre em ata o que temos discutido na lista, no que concerne ao esclarecimento público quanto ao que realmente está acontecendo com a applet, uma vez que as notícias que têm sido veiculadas distorcem a realidade atribuindo ao PJe uma falha. Não se opôs ao pedido de rediscussão do tema, em especial se o representante da OAB apresentar sugestões técnicas para deliberação.

<<< Discussões e deliberações sobre o ponto "b" >>>


Pauta

1. Bloqueio do Java devido a sua atualização

O coordenador do comitê esclareceu que:

- em razão dos riscos de golpes de internet, os fabricantes de software utilizados nesse ambiente têm se esforçado para garantir que eles fechem as portas para vulnerabilidades tão logo elas sejam descobertas. Isso faz com que os navegadores tenham um mecanismo automatizado de detecção de novas versões de seus plugins, de forma a bloquear o uso de plugins desatualizados tão logo uma nova versão seja disponibilizada pelo fabricante do plugin; - a plataforma Java em cliente é executada em um plugin do navegador (o Java Plugin), instalado pelos usuários por meio do Java Runtime Environment. Esse plugin é atualizado com periodicidade aproximadamente trimestral por sua fabricante (Oracle Corp.), mas podem e têm havido liberações ou atualizações em intervalos menores de tempo em razão da constatação de vulnerabilidades graves exploradas por hackers. Mais que isso, toda a política de segurança na execução de mini-aplicativos java em navegadores foi modificada no ano de 2013. - no PJe, é necessária a utilização dessa plataforma java para a realização da autenticação do usuário e de suas assinaturas digitais nos documentos, uma vez que ainda não há um padrão tecnológico que permita utilizar funções dos navegadores para acessar o dispositivo criptográfico de modo a realizar essas funções. No ano de 2013, em razão das sucessivas modificações de política de segurança do JRE nos navegadores - algumas delas contraditórias entre si -, tivemos que liberar três versões diferentes da applet durante o ano, a última delas no dia 08/11/2013. Essa última versão da applet (1.0.8) é aderente à todas às políticas da versão 1.7.0_45 do JRE, tendo sido mantidas as políticas na versão lançada no dia 14 próximo passado (1.7.0_51). Após a liberação da versão 1.0.8, foram lançadas novas versões do PJe contendo a nova applet nas famílias 1.4.6.x, 1.4.7.x, 1.5.x e 1.6.x. - a atualização da versão do JRE no dia 14/01/2013 em *nada impacta* os usuários, desde que o tribunal esteja utilizando a versão de produção mais moderna do PJe e o usuário mantenha seu computador atualizado; - embora tenhamos estimativas de lançamento das próximas versões do Java (a próxima é em 14/04/2014, com expiração da versão atual em 15/04/2014), nada impede que a Oracle Corp. lance versões em intervalos mais curtos ou mesmo que a política de segurança dos navegadores também seja modificada. Temos nos esforçado para acompanhar essas mudanças e continuaremos assim. Estamos estabelecendo uma política de comunicação social de modo a alertar quanto à necessidade de atualizar seu computador nas proximidades das datas prováveis de atualizações. - solicitamos que os tribunais mantenham seus PJes atualizados, o que, esperamos, será mais fácil agora que a Resolução 185 foi aprovada. - no que toca à eventual supressão do uso de mini-aplicativo java para assinatura, têm sido pesquisadas alternativas de soluções que tornem a assinatura digital independente do uso de plugins, mas é necessário, para isso, que haja a consolidação e aprovação definitiva de um padrão Web a respeito, o que está em discussão na W3C e cuja conclusão está prevista para 2015. Em síntese, foi observado o seguinte cronograma pela Gerência do Projeto:

Em 13.01.2013, a versão 1.7.0_u10 do JRE informou que em versão futura, àquela época ainda indefinida, seria exigida assinatura confiável das aplicações em linguagem Java.

Em 11.11.2013, a aplicação de assinatura para autenticação de usuários no PJe foi lançada com assinatura digital válida do CNJ, com ajustes prevenindo as modificações anteriormente anunciadas no JRE e até aquele momento não postas em prática.

Em 14.01.2014, a versão 1.7.0_u51 do JRE foi lançada, a fim de solucionar, principalmente, três falhas de segurança e finalmente implementar a exigência divulgada em 13.01.2013. Não foi necessária modificação na aplicação do PJe, que tem assinatura digital confiável do CNJ desde 11.11.2013, bastando a atualização do Java JRE no computador do usuário.

Em 15.01.2014, a gerência técnica do PJe emitiu avisos aos tribunais, solicitando que divulgassem a seus usuários a necessidade de atualizarem o software Java JRE em seus equipamentos, e encaminhou passo-a-passo aos representantes das entidades parceiras que integram o comitê gestor do PJe (OAB, Ministério Público, AGU, Defensorias etc.), permitindo ampla divulgação.


<<< Discussões de deliberações sobre o ponto 1 >>>


2. Compartilhar o sistema PJe com a Secretaria de Direitos Humanos.

A Secretaria de Direitos Humanos requer lhe seja compartilhado o código-fonte do sistema PJe, para virtualização dos processos administrativos em trâmite no órgão. O Comitê-Gestor do PJe já deliberou acerca da impossibilidade de cessão do código-fonte, salvo situações excepcionais. O requerimento em exame é dotado da mencionada excepcionalidade, pois o compartilhamento do código-fonte, na hipótese, pode dar início a um braço administrativo do PJe. Essa opção implicaria a necessária modificação do escopo inicial do projeto. Por outro lado, pode facilitar a difusão do sistema, bem como contribuir para a sua aceitação geral. Do ponto de vista de custo para o CNJ, como mencionado no ofício, seria restrito à apresentação inicial do sistema e seu funcionamento. A customização ficaria completamente a cargo da Secretaria de Direitos Humanos, que possui fábrica de software própria. Importante ressaltar, ainda, que o compartilhamento do código-fonte favoreceria o amadurecimento e a aplicação do MNI, posto que os órgãos que interagem nos processos administrativos com a Secretaria de Direitos Humanos necessariamente passariam a adotar a linguagem. O código-fonte do PJe é propriedade intelectual da União, não havendo óbice ao compartilhamento com o órgão requerente quanto a esse aspecto. Ressalto, todavia, que caso se entenda por compartilhar o código-fonte, é mister que se preserve o controle do CNJ, ficando a Secretaria de Direitos Humanos impedida de repassá-lo a outros órgãos públicos sem a autorização prévia deste Comitê Gestor. Feitas essas considerações, o requerimento é submetido ao Comitê Gestor.

<<< Discussões de deliberações sobre o ponto 2 >>>

3. Autorizar a utilização do aplicativo de assinatura do PJe (applet de assinatura) para o sistema SIGA-DOC.

Conforme deliberado na 41ª Reunião deste Comitê, o aplicativo de assinatura de documentos do PJe deve ser utilizado exclusivamente em projetos do próprio CNJ. Em futuro próximo o CNJ passará a utilizar o sistema SIGA-DOC para controle de procedimentos internos. A princípio, não existira objeção à utilização da applet de assinatura. Ocorre que o SIGA-DOC é um projeto proveniente do TRF2, de modo que a utilização da applet de assinatura nesse sistema implicará a sua posterior cessão a outros órgãos do Poder Judiciário que pretendam utilizar o SIGA-DOC.

Repetem-se, no caso, os argumentos lançados na 41ª Reunião: Do ponto de vista legal, o código-fonte pertence à União Federal e, ainda que este comitê seja o gestor da propriedade intelectual direta, a Comissão de Tecnologia da Informação e Infraestrutura tem o poder de liberar sua utilização para outros sistemas no CNJ ou fora dele. A liberação desse código-fonte, porém, pode levar à constatação de eventuais fragilidades ainda não conhecidas da applet, o que pode afetar a segurança do PJe.

Por outro lado, o compartilhamento do código-fonte com outras equipes - do CNJ ou fora dele - pode levar a um amadurecimento melhor da aplicação, inclusive quanto à segurança.

Submete-se ao comitê-gestor solicitação para que se opine quanto à autorização para liberação do código-fonte do aplicativo de assinatura para o SIGA-DOC.

<<< Discussões de deliberações sobre o ponto 1 >>>

4. Análise da melhoria JIRA com número PJEII-14370, registrada pelo TJRN.

Em síntese, o TJRN discorda da regra de negócio RN376, que diz que o advogado poderá solicitar habilitação nos autos apenas para o polo passivo e para partes desse polo que ainda não têm advogado/procurador constituído, abaixo transcrita:

Essa funcionalidade permite que um advogado se habilite em um processo em andamento. Por exemplo, uma parte x (polo ativo) entra com uma ação, representada por seu advogado, contra uma outra parte y (polo passivo). A parte y, inicialmente, não tem advogado constituído. Sendo assim, quando y constituir advogado, ele (o advogado), de posse do nº do processo e da procuração respectiva, poderá solicitar habilitação nos autos para representar o seu cliente. O advogado solicita habilitação e o magistrado examina a petição e documentos anexados na solicitação de habilitação, mas a habilitação é realizada automaticamente. Para solicitar habilitação representando partes que já constituíram advogado, o advogado deve ir ao juizado e entregar a petição, que será anexada ao processo pelo usuário do juizado, fazendo a retificação da autuação incluindo o advogado na relação processual e vinculado à parte que deve ter sido informada na petição. Deve ser observada ainda, a regra RN300 quando se tratar de processo em segredo de justiça. Para perfis que não devem ter acesso à funcionalidade, o sistema não deve disponibilizar o menu ou deve impedir a utilização, utilizando como referência a mensagem MN176.

O argumento é de que "não deveria existir nenhuma restrição de solicitação de habilitação nos autos, uma vez que os atos praticados pelos advogados estão garantidos pelo seu certificado digital, e que há a possibilidade do próprio advogado juntar o subestabelecimento no próprio sistema, se lhe fosse permitido".

<<< Discussões de deliberações sobre o ponto 1 >>>

Próxima reunião do comitê gestor

Ferramentas pessoais
Espaços nominais

Variantes
Ações
Navegação
Informações Gerais
Aplicativos PJe
Manuais
Suporte
Ferramentas