[IRPF-Livre, Rnetclient] Impossível enviar declaração

[Alexandre Oliva]

On May 22, 2026, Adonay Felipe Nogueira <adfeno.7046 en gmail.com> wrote:

> Como lxoliva informou na sala usuarios-gnu no XMPP que pode ser que as
> mudanças foram feitas de 2024 para 2025

Pode ser que tenham mudado o receitanet.jar usado pelo IRPF bem antes
disso.  O que eu não tinha percebido quando sugeri essa possibilidade é
que tinham mudado este ano.  Por alguma razão eu achei que o
receitanet.jar continuava inalterado, e tomei algumas decisões infelizes
por causa dessa crença.


Hoje comecei a tentar entender o funcionamento do novo receitanet.

Talvez a primeira descoberta talvez útil é que há um aplicativo
receitanet naquele .jar.  Pode ser iniciado a partir do diretório que
contém o irpf.jar, rodando:

  java -cp lib/jsignnet-3.6.0.jar:lib/maven-artifact-3.8.4.jar:lib/bcprov-jdk18on-1.75.jar:lib/bcmail-jdk18on-1.75.jar:lib/bcpkix-jdk18on-1.75.jar:lib/bcutil-jdk18on-1.75.jar:lib/recnetutil-1.1.jar:lib/recnet-envelope-1.2.jar:lib/receitanet-pro-1.32.jar serpro.receitanet.gui.ReceitanetApp

O fato de que isso funciona sugere pra mim que, para fins de
experimentação, poderíamos escrever um Main alternativo que, como o IRPF
lib-modulos/irpf-gui-basica.jar.src/serpro/ppgd/irpf/gui/basica/dialogs/PainelGravarTransmitir.java
chame ((ControleReceitaNet)recnet).enviarDeclaracao(Window, File,
boolean, StringBuffer).  Pelo que entendi, File é pra ser o .DEC, o
boolean é pra indicar se é pra transmitir usando certificado digital, e
o StringBuffer é pra ser vazio pra chamada devolver mensagens.  Window
seria a janela principal para interação, não sei se pode ser null ou se
precisa mesmo criar alguma coisa.


Outra descoberta talvez útil é que quem faz a validação do
receitanet.jar a partir do sha1 em receitanet.dat é o próprio, em
ControleReceitanet.a().  Em tese (porque não testei) bastaria explodir o
.jar e usar o diretório em vez do .jar no classpath que ele deixa de
verificar.  Aí poderíamos substituir classes para experimentar, por
exemplo, adicionar código para nos informar o que está acontecendo, o
que está sendo enviado, o que está sendo recebido, enfim...


Com um programinha de linha de comando que só faz o envio, ou mesmo só
prepara pra fazer o envio, podemos começar a entender o que está
acontecendo ali, com prints ou com um depurador.


Do que eu entendi até agora, parece que:

- o enviarDeclaracao instancia um w (e não um y) com o arquivo .DEC,
  porque creio que envelope.importar não tem como encontrar os tags
  esperados no .DEC.  Daí cria uma lista com esse w, uma lista de mesmo
  tamanho com o booleano (de certificação) convertido pra inteiro, um
  array de String[]s e um de Integer[]s e chama a(Window, List, List,
  String[], Integer[]) para iterar sobre as listas e transmitir as
  declarações

- parece que podemos evitar a confirmação, se é que há alguma,
  inicializando ControleReceitanet.b = false em vez de true no
  construtor, ou em serpro/receitanet/recursos/receitanet.properties
  build.producao=true (já é) ou teste.nao_exibir_mensagens=true

- nesse arquivo há um gui.progresso.exibir=true que talvez possamos
  desligar para evitar precisar de uma janela.  a testar...

- também há um número de versão.  infelizmente colocar esse número de
  versão no rnetclient não foi suficiente para ele funcionar

- w.R() lembra bastante o rnet_encode() do rnetclient

- aL.a(String, int, c) é onde conexões com o servidor são estabelecidas

- aG é onde a camada de SSL/TLS é introduzida

- parece-me que ap.a() é onde a transmissão acontece, mas foi só até
  aqui que eu cheguei na exploração do código por enquanto

-- 
Alexandre Oliva, happy hacker            https://blog.lx.oliva.nom.br/
Free Software Activist     FSFLA co-founder     GNU Toolchain Engineer
Learn the truth about Richard Stallman at https://stallmansupport.org/