Interface gráfica de 7 telas e um CLI scriptável para lotes de petições. O ato criptográfico é do JSignPdfC + PKCS#11 StarSign já homologados na sua máquina; o Assinador JurisDelfus cuida do lote, do carimbo, do PIN e da validação de cada documento antes de gravá-lo.
JSignPdfC -V --img-path assets/carimbo_transparente_600.png \
-kst PKCS11 -ksf ~/.config/jsignpdf/pkcs11.cfg \
-ka "JOAO RAFAEL FONTENELES ABREU" -ki 0 \
-d <saida> -os _assinado --enable-stdin-passwords -ksp - <doc.pdf>
Tudo abaixo é comportamento implementado, não intenção de design.
A assinatura entra como revisão incremental. Trabalhamos numa cópia em diretório temporário e o destino só recebe o arquivo depois de verificado.
Nenhum campo de texto do app segura sua senha. O PIN é escrito em uma linha no stdin
do processo filho — invisível em ps aux e em qualquer log.
Extraímos o vão do /ByteRange e rodamos openssl cms -verify.
Falhou a verificação? O lote registra a falha e o arquivo inválido não chega a você.
A versão errada do libaetpkss.so assina com dados corrompidos. O diagnóstico
recusa o driver que não seja o homologado, com o SHA-256 na tela.
Do splash ao relatório assinado. Cada tela abaixo é uma imagem de projeto — a numeração é a ordem real de navegação do app.
Splash com a balança e a promessa do produto: nenhuma palavra sobre “driver”, “PKCS#11” ou caminho de binário. O usuário entende em 2 segundos o que o app faz.
O app confere sozinho o que precisa existir na máquina: o `JSignPdfC`, o `pkcs11.cfg`, o `openssl` e — principalmente — o **hash do driver do token**. Cada linha é ✓ ou ✗ com o caminho absoluto do lado, para colar no suporte.
Lote, não arquivo solitário: arraste N petições, escolha o sufixo de saída (`_assinado`) e a pasta de destino. Os originais ficam intocados — o que aparece na lista é o que será lido, nunca sobrescrito.
Página e canto do carimbo com pré-visualização do PNG real da marca dentro da folha. A linha embaixo mostra as flags que irão ao JSignPdf (`-llx/-lly/-pg`); elas só entram no comando se você ligar o checkbox.
Antes de assinar, o resumo do que vai acontecer: binário, configuração PKCS#11, alias do certificado, carimbo e posição. Nada é escondido do usuário.
O PIN é pedido pelo `pinentry` do sistema — nunca por campo de texto do app, nunca por argv. A barra dourada avança por arquivo e o log aceita cancelamento entre um PDF e outro.
Relatório por arquivo: `openssl cms -verify`, SHA-256 em destaque com o selo VERIFICADO, `/ByteRange`, tamanho do CMS e a ferramenta usada. Abas separam o que deu certo do que falhou — sem “sucesso parcial”.
O Assinador JurisDelfus não implementa CMS/PKCS#7 nem fala com o token por conta
própria. Ele monta o comando homologado, executa com subprocess (lista de
argv, sem shell), coleta o PDF gerado, verifica e entrega — mantendo seu carimbo
transparente no lugar escolhido.
JSignPdfC em modo CLI, -kst PKCS11,
configuração pkcs11.cfg e alias do certificado lidos do token-V --img-path e flags de posição
-llx/-lly/-pg sob seu controle (ligável por checkbox ou --extra)assinador.cli sign
--pin-from-stdin# assinatura válida = exatamente esta linha, na sua máquina
openssl cms -verify -in sig.der -inform DER -content content.bin \
-noverify -binary -out /dev/null
CMS Verification successful
O relatório da última tela não mostra um checkmark verde: mostra o que o OpenSSL respondeu, o hash do arquivo e o vão coberto pela assinatura.
python3 - <<'PY'
import re
data = open("peticao_assinado.pdf","rb").read()
a,b,c,d = map(int, re.search(rb"/ByteRange\s*\[\s*(\d+) (\d+) (\d+) (\d+)\s*\]", data).groups())
assert c + d == len(data)
open("/tmp/content.bin","wb").write(data[a:a+b] + data[c:c+d])
open("/tmp/sig.der","wb").write(bytes.fromhex(
re.search(rb"/Contents\s*<([0-9A-Fa-f]+)>", data).group(1).decode()))
print("vão coberto:", b + d, "bytes")
PY
openssl cms -verify -in /tmp/sig.der -inform DER \
-content /tmp/content.bin -noverify -binary -out /dev/null
CMS Verification successful
A tela 6 e o CLI rodam exatamente essa sequência:
localizam o /ByteRange mais recente, montam o conteúdo coberto, extraem o DER de
/Contents (antes ou depois do marcador, conforme o gerador) e chamam o
openssl. Se a resposta não for “Verification successful”, o arquivo não é
entregue — e a tela diz o motivo com o texto cru da ferramenta.
Requisitos: Linux com python3-tk, openssl e o
assinador já instalado em /opt/jsignpdf. O instalador (.run/.deb) é a etapa
seguinte, deliberadamente adiada até o fluxo estar validado no ambiente real.