0.5.1

Adicionado

• remoteid servir: a visão traz o DER de cada certificado (certificado), e o
  formato cru aceita um DigestInfo pronto (digest_info), para assinar o
  resumo de qualquer algoritmo, como o SHA-384 e o SHA-512 que o TLS 1.2 pede.

Instalar

No Âncora, pela tela de extensões dele ou pelo terminal:

flatpak remote-add --user --if-not-exists ancora https://flatpak.lukakuuhaku.dev/ancora.flatpakrepo
flatpak install --user ancora dev.lukakuuhaku.Ancora dev.lukakuuhaku.Ancora.Driver.RemoteID

No Tessera, pelo FlatPark:

flatpak remote-add --user --if-not-exists flatpark https://dl.flatpark.org/flatpark.flatpakrepo
flatpak install --user flatpark io.github.pedrohqb.Tessera io.github.pedrohqb.Tessera.Driver.RemoteID

Num servidor, remoteid-servidor-x86_64.tar.gz traz o remoteid sem a janela, estático, para qualquer Linux x86_64; remoteid servir é a API. remoteid-x86_64.tar.gz traz o programa com a janela e o módulo PKCS#11, compilados no GNOME 51.

0.5.0

Adicionado

• remoteid servir: tudo o que a janela faz, como API em JSON por linha, no
  stdin e stdout ou num socket Unix só do usuário (--socket <caminho>). O
  código do autenticador é pedido a quem chama, pelo mesmo canal, e a senha
  guardada nunca sai por ele. O protocolo está em docs/servico.md.
• Os subcomandos estado (com --json), atualizar, usar, reautorizar,
  sair e ajuda, e assinar --certificado para assinar com um certificado
  que não é o ativo.
• O RemoteID compila sem GTK (cargo build --no-default-features): sem a
  janela e o diálogo, com todos os outros subcomandos.
• A release traz remoteid-servidor-x86_64.tar.gz: o remoteid sem a
  janela, estático, para servidores com qualquer Linux x86_64.

Instalar

No Âncora, pela tela de extensões dele ou pelo terminal:

flatpak remote-add --user --if-not-exists ancora https://flatpak.lukakuuhaku.dev/ancora.flatpakrepo
flatpak install --user ancora dev.lukakuuhaku.Ancora dev.lukakuuhaku.Ancora.Driver.RemoteID

No Tessera, pelo FlatPark:

flatpak remote-add --user --if-not-exists flatpark https://dl.flatpark.org/flatpark.flatpakrepo
flatpak install --user flatpark io.github.pedrohqb.Tessera io.github.pedrohqb.Tessera.Driver.RemoteID

Num servidor, remoteid-servidor-x86_64.tar.gz traz o remoteid sem a janela, estático, para qualquer Linux x86_64; remoteid servir é a API. remoteid-x86_64.tar.gz traz o programa com a janela e o módulo PKCS#11, compilados no GNOME 51.

0.4.1

Adicionado

• O módulo PKCS#11 registra as chamadas de navegadores e assinadores (função,
  mecanismo, código de retorno e duração), sem o PIN nem os dados assinados.
  As chamadas de rotina só vão ao disco junto de um erro ou de uma
  assinatura, e o registro guarda as últimas 64 antes delas.
• Cada registro começa com a versão, o aplicativo hospedeiro, o runtime e o
  sistema, e um erro interno do módulo deixa a mensagem e o local.
• remoteid diagnostico > remoteid-diagnostico.tar.gz empacota os registros e
  o ambiente para anexar a um relato de erro.
• A release traz remoteid-x86_64.tar.gz, com o programa e o módulo PKCS#11
  compilados no GNOME 51, para quem empacota o RemoteID fora do Âncora.

Alterado

• Os registros ficam 30 dias, até 64 MiB somados, em vez dos 20 mais novos, e
  a janela grava um registro só por vez que é aberta.
• O id do aplicativo vem do hospedeiro: a janela do RemoteID abre em outro
  hospedeiro de extensões, e no Âncora nada muda.

Instalar

O RemoteID é uma extensão do Âncora: instale pela tela de extensões dele, ou pelo terminal:

flatpak remote-add --user --if-not-exists ancora https://flatpak.lukakuuhaku.dev/ancora.flatpakrepo
flatpak install --user ancora dev.lukakuuhaku.Ancora dev.lukakuuhaku.Ancora.Driver.RemoteID

0.4.0

Adicionado

• A extensão dev.lukakuuhaku.Ancora.Driver.RemoteID do Âncora, com a janela
  do RemoteID e o módulo PKCS#11.
• O módulo PKCS#11 assina sozinho, com só o serviço do Âncora no ar: mostra o
  certificado da carteira como token e, quando a sessão em cache não vale
  mais, abre uma janela que pede o código do autenticador.
• O token traz a cadeia de autoridades do certificado, baixada do
  caIssuers, para os assinadores que montam a cadeia pelo token.
• Um navegador aberto vê o certificado quando a conta é preparada ou trocada,
  sem precisar ser reiniciado, mesmo que tenha sido aberto antes de entrar na
  conta: sem conta, o Âncora já publica o RemoteID, com o token vazio.
• remoteid entrar <email> entra na conta, registra a máquina e baixa a
  carteira, com a senha pelo stdin.
• remoteid assinar assina o que chega pela entrada padrão e devolve um
  .p7s na política AD-RB da ICP-Brasil (destacado, ou com --anexar o
  documento dentro), ou com --cru só a assinatura RSA. O código do
  autenticador é pedido na mesma janela do módulo, ou no terminal quando o
  programa roda fora do Flatpak.
• remoteid harness testa o fluxo com a conta entrada e grava um relatório
  sem senha, PIN, OTP nem o titular.
• A janela do RemoteID: entrar na conta, o certificado que assina como um
  cartão com o estado da sessão (aberta até que horas, ou pedindo o código),
  trocar de certificado passando o cartão, detalhes com a cadeia e a conta,
  reautorizar e sair, com "Desfazer". Acompanha as assinaturas feitas com ela
  aberta.
• A senha da conta fica no chaveiro do sistema: a assinatura pede só o código
  do autenticador. Sem chaveiro, a senha fica cifrada no computador com um PIN
  de 4 a 6 dígitos, criado ao entrar e pedido uma vez por aplicativo aberto;
  cinco PINs errados seguidos apagam a senha e saem da conta.

Mudado

• O RemoteID deixa de ter instalador próprio: é uma extensão do Âncora, e o
  módulo PKCS#11 é publicado pelo Âncora para os navegadores e aplicativos.
  Quem tem a v0.3.2 instalada a desfaz antes (ver o README); a conta é
  entrada de novo.
• O .p7s passa a seguir a política AD-RB v2.4 da ICP-Brasil, com o
  identificador da política que a v0.3.2 não punha.
• O "PIN" que a assinatura pedia era a senha da conta: agora ela fica guardada,
  e só o código do autenticador é pedido.

Removido

• O instalador (install.sh, instalar.sh, desinstalar.sh), o daemon e os
  comandos remoteid estado, conectividade, login, registrar,
  carteira, celular, preparar, modo, chave-publica e diagnostico:
  a janela e o remoteid entrar fazem a preparação, e o diagnóstico fica no
  remoteid harness.
• A aprovação pelo celular (push), que nunca passou por uma conta real.

Instalar

O RemoteID é uma extensão do Âncora: instale pela tela de extensões dele, ou pelo terminal:

flatpak remote-add --user --if-not-exists ancora https://flatpak.lukakuuhaku.dev/ancora.flatpakrepo
flatpak install --user ancora dev.lukakuuhaku.Ancora dev.lukakuuhaku.Ancora.Driver.RemoteID

v0.3.2

Corrigido

• O diagnóstico não grava mais os dados pessoais do certificado (issue
  #30). A cada assinatura o servidor devolve o certificado do titular já
  parseado, e o JSONL em diag/ guardava nome, CPF, RG, e-mail, data de
  nascimento, título de eleitor e o resto em claro, inclusive no relato que
  vai para terceiros. Esses campos agora saem como <redigido>, mesmo com
  REMOTEID_DIAG_RAW=1. O serial do certificado (em qualquer das grafias do
  protocolo), a cert_key e a signatureBase64 saem como impressão digital,
  o que ainda permite saber se duas linhas falam do mesmo certificado. Emissor
  e validade continuam legíveis, porque é com eles que se diagnostica
  certificado vencido ou de outra AC. Os arquivos de diagnóstico gravados
  antes desta versão continuam com os dados: apague-os de diag/ se for
  enviá-los.

• O título "Segurança & Sessão" das configurações volta a aparecer
  (issue #29). O GTK lê esse título como markup, e o & sem escape fazia ele
  recusar o texto, com um aviso no log a cada abertura da tela. Pelo mesmo
  motivo, nome do titular, emissor, unidades organizacionais e o caminho do
  log passam a ser mostrados como texto puro: um certificado de empresa como
  "FULANO & CIA LTDA" deixaria a linha em branco.

v0.3.1

Corrigido

• Fechar a janela não desliga mais o assinador (issue #26). Fechada a
  última janela, o app terminava e apagava o socket; o certificado continuava
  aparecendo no PJeOffice e no navegador (quem o lista é o módulo), mas toda
  assinatura falhava com CKR_DEVICE_ERROR, sem nada no diag, e o
  "Reautorizar" não adiantava porque o problema era o app fechado. Agora fechar
  a janela só a esconde: o app segue no ar atendendo o socket e avisa isso
  numa notificação na primeira vez. Para encerrar, Sair no menu da janela
  (Ctrl+Q).

• Abrir o app de novo não cria mais um segundo serviço (issue #26). Com o
  app já aberto, uma nova abertura (pelo menu ou pela janela do Adv BR) montava
  outra janela com outro motor e refazia o socket para ele; as janelas antigas
  ficavam ligadas a um serviço que não atendia mais ninguém, e um "Reautorizar"
  numa delas não valia para a próxima assinatura. Agora a segunda abertura só
  traz de volta a janela que já existe.

• Pedido de assinatura sem o app no ar deixa rastro (issue #26). O módulo
  passa a registrar em modulo-pkcs11.jsonl, no diretório do diag, quando não
  acha o app (assinatura.sem_app) ou quando o app aceita o pedido e não
  responde (assinatura.sem_resposta), com o socket procurado e o programa que
  pediu. Antes essa falha não aparecia em lugar nenhum e parecia problema de
  protocolo.

v0.3.0

Corrigido

• O token passa a publicar a cadeia de autoridades, e o assinador do
  Projudi (TJPR) deixa de enviar a assinatura sem ela (issue #22). O token
  expunha só o certificado final, o SunPKCS11 devolvia uma cadeia de tamanho 1,
  e o assinador do TJPR caía num caminho de completar a cadeia que está
  quebrado do lado dele; o servidor recusava com "Trust anchor for
  certification path not found". Agora o app baixa as ACs do caIssuers do
  próprio certificado (o .p7c da Certisign, que traz a cadeia até a raiz),
  guarda no state.json e o módulo as publica como CKO_CERTIFICATE de
  autoridade, ao lado do certificado do titular, sem parear com a chave. O
  download acontece no preparo e, para instalações que já existiam, na
  primeira vez que o app abre depois da atualização; o módulo continua sem ir
  à rede. Se o download falhar, o token segue como antes e o motivo vai ao
  diag. Com a cadeia no token, o findCertificate do assinador do TJPR
  continua vendo um certificado só e escolhendo sozinho.

• PIN recusado pelo servidor não volta mais preenchido, e a recusa aparece
  para o titular (issue #21). O diálogo guardava o PIN no cache antes de o
  tokensessao aceitá-lo, então um PIN errado voltava preenchido (com o foco
  já no OTP) em cada assinatura dos 5 minutos seguintes, e cada reenvio podia
  contar para o bloqueio do certificado. Agora o PIN só entra no cache depois
  de aceito, e uma recusa limpa o cache. Na recusa de PIN ou OTP, o diálogo
  reabre dentro da mesma assinatura com a mensagem do servidor e o PIN vazio,
  até 3 tentativas; esgotadas, o módulo responde CKR_PIN_INCORRECT em vez de
  CKR_FUNCTION_FAILED, que o PJeOffice mostrava como stack trace. A
  mensagem "PIN ou e-Token incorreto" ganhou dica própria no diag: antes ela
  caía na do "e-token", que afirmava, errado, que o PIN tinha sido aceito.

Segurança

• rustls 0.23.45, que corrige o RUSTSEC-2026-0285 (#20). A versão anterior
  aceitava mensagens de handshake TLS 1.3 enviadas no nível de criptografia
  errado, quando vinham no mesmo registro de uma mensagem que troca a chave. O
  transcript continua autenticado, então não dá para alterar um handshake por
  aí; o efeito é aceitar em texto claro mensagens que deveriam vir cifradas. O
  rustls entra pelo ureq, no transporte até o servidor RemoteID.

v0.2.0

Adicionado

• O módulo PKCS#11 anuncia CKF_ENCRYPT em CKM_RSA_PKCS e cifra com a
  chave pública (issue #10). O PJeOffice não autenticava no Linux: o
  signer4j precisa de RSA cru pela JCA, e a única porta é o
  Cipher.RSA/ECB/PKCS1Padding do SunPKCS11, que desde o JDK-8176837 só é
  registrado se o mecanismo anunciar CKF_ENCRYPT. Com a chave privada em
  ENCRYPT_MODE o Java faz C_SignInit + C_Sign, que já existiam; o que
  faltava era o anúncio. C_EncryptInit/C_Encrypt passam a existir de
  verdade, só com a chave pública (a privada recebe
  CKR_KEY_FUNCTION_NOT_PERMITTED), sem socket e sem PIN. É uma divergência
  deliberada do módulo oficial, que é sign-only. A prova em Java
  (tools/prova-jca-pkcs11/ProvaCipher.java) entra no gate de integração.
• Modo cru no caminho de produção (issue #11). A sondagem ao vivo de
  05/09/2026 provou que o requestHashSessionSignature com algorithm: ""
  só aplica o padding PKCS#1 v1.5 ao bloco enviado. O CKM_RSA_PKCS do
  módulo passa a mandar o bloco inteiro nesse modo, seja qual for o hash
  dentro dele; o verbo sign do socket ganha o campo algoritmo (opcional,
  padrão SHA256); o motor e o daemon recebem um Algoritmo tipado, com a
  regra de tamanho num lugar só. É o que faz o DigestInfo(MD5) do
  PjeAuthenticatorTask chegar assinado ao PJeOffice. O mock imita o
  servidor medido, inclusive a forma exata da recusa.
• O diag registra quem pediu cada assinatura. Evento assinatura.pedido
  com hospedeiro (o comm do processo que chamou o C_Sign: papers,
  firefox, java), algoritmo e bloco_bytes. É a linha que responde,
  num relatório de bug, qual app disparou a assinatura.

Alterado

• CKM_RSA_PKCS deixa de reconhecer DigestInfo. Antes, em produção, o
  módulo desmontava um DigestInfo(SHA-256) de 51 bytes para mandar só o hash,
  aceitava 32 bytes crus como se fossem o hash (e o servidor os embrulhava em
  DigestInfo), e recusava qualquer outro tamanho com CKR_DATA_LEN_RANGE.
  Agora o bloco vai como está, de 1 a 245 bytes, e recebe só o padding, que é
  o que a especificação define e o módulo oficial faz. Quem quer DigestInfo
  manda DigestInfo (poppler, NSS, OpenSSL e o SunPKCS11 já mandam); a
  assinatura desses continua byte a byte a mesma.

Corrigido

• C_SignInit com sessão inexistente devolve CKR_SESSION_HANDLE_INVALID,
  e não um pânico convertido em CKR_GENERAL_ERROR.

Interno

• O remoteid-mock aceita uma carteira de fora, por
  REMOTEID_MOCK_FIXTURES=<dir> (cert.der, key.pem, keyname.txt). Serve
  para rodar contra um certificado com a forma e o conteúdo de um real, que a
  fixture sintética não reproduz (as extensões otherName da ICP-Brasil, os
  vários OUs, os acentos no DN) e que não pode ser versionado, porque
  identifica uma pessoa. Sem a variável nada muda; com ela apontando para um
  diretório imprestável o mock morre, em vez de cair de volta na fixture
  embutida e exibir outra identidade.
• Testes de mutação (cargo mutants, 327 mutantes em 8 crates) fecharam os
  buracos que importavam: o guarda do retry silencioso com cache válido (um bug
  ali gastaria um OTP por recusa), o braço CKM_SHA256_RSA_PKCS de
  preparar_bloco, os handles de sessão do módulo, e o cliente do socket, que
  só o gate ponta a ponta exercita.
• O passo da cifra no gate de integração exige OpenSC 0.26+ e é pulado onde
  a ferramenta é mais velha. O pkcs11-tool do Ubuntu 24.04 (0.25) procura uma
  chave secreta e falha antes de chamar o módulo, o que deixava o CI vermelho
  por causa da ferramenta. A cobertura fica com o -M, com a prova em Java e
  com os testes de ABI.

v0.1.2

Corrigido

• Assinatura em fluxo no módulo PKCS#11 (issue #7). C_SignUpdate e
  C_SignFinal não eram implementados, e quem assina em fluxo nunca chama
  C_Sign: o BouncyCastle escreve o documento num
  SignatureUpdatingOutputStream, que vira C_SignInit → C_SignUpdate(n) →
  C_SignFinal. Na prática, o PJeOffice recebia
  CKR_FUNCTION_NOT_SUPPORTED no primeiro update e não conseguia assinar.

  C_SignUpdate agora acumula os pedaços na sessão e C_SignFinal assina o
  acumulado, pelo mesmo caminho de assinatura do C_Sign — a assinatura sai
  idêntica para o mesmo conteúdo. Sem C_SignInit antes, ambos devolvem
  CKR_OPERATION_NOT_INITIALIZED; depois do C_SignFinal a operação termina,
  dê certo ou não.

Interno

• make check passou a espelhar o job do CI (cargo fmt --all --check, testes,
  clippy com -D warnings e build de release). Antes o alvo local aprovava o
  que o CI reprovava, e a divergência apareceu num pull request.

v0.1.1

Torna o projeto instalável como aplicativo de verdade: ele agora tem ícone,
aparece no menu e sai do tarball com um instalador, em vez de exigir que cada
pessoa espalhe arquivos à mão.

Adicionado

• Ícone do aplicativo, colorido e symbolic (dev.lukakuuhaku.RemoteID).
  Nuvem porque a chave do certificado mora no HSM da Certisign e não na máquina;
  selo dentado porque é certificação. O symbolic é um desenho próprio, não uma
  redução: a 16px o selo vira borrão, então lá a nuvem é sólida e o check é
  vazado nela.
• Lançador .desktop, com StartupWMClass casando o application id — é o
  que evita o compositor mostrar dois ícones na barra.
• instalar.sh e desinstalar.sh, também expostos como make instalar e
  make desinstalar. Instalam em ~/.local sem root, registram o módulo no
  p11-kit e atualizam os caches de ícone e de lançador. O desinstalador
  preserva o estado da conta em ~/.local/state/remoteid: apagá-lo exigiria
  novo login e registro.
• O pacote da release passa a incluir o aplicativo gráfico (remoteid-app),
  o ícone, o lançador e o instalador. Antes trazia só a CLI e o módulo, e um
  .desktop ali dentro apontaria para um binário inexistente.

Modificado

• O remoteid-app distribuído no tarball exige GTK4 e Libadwaita instalados
  na máquina. A CLI (remoteid) e o módulo PKCS#11 continuam sem depender de
  nada além do sistema base.