https://github.com/regyssilveira/Boss4Delphi

O Boss4D 1.6.0 aprofunda uma transformação iniciada nas versões anteriores:
deixar de ser apenas uma ferramenta para clonar dependências Git e tornar-se
uma plataforma completa de gerenciamento, distribuição e auditoria de pacotes
para Delphi e Lazarus.

Se a versão 1.5.0 estabeleceu as fundações para pacotes imutáveis, conformidade
e execução nativa com Free Pascal, a versão 1.6.0 conecta essas peças em fluxos
de produção. O Registry ganhou um protocolo mais eficiente, os pacotes podem
ser instalados com verificação de integridade e proveniência, a CLI Linux passou
a cobrir o trabalho cotidiano de um projeto e o processo de publicação recebeu
novas garantias.

Neste artigo, veremos o que mudou, quais problemas essas capacidades resolvem e
como começar a utilizá-las.

O que há de novo no Boss4D 1.6.0

Os destaques desta versão estão concentrados em cinco áreas:

• Registry v2 com índices compostos, metadados sparse e cache HTTP;
• instalação transacional de pacotes .b4dpkg verificáveis;
• CLI Linux/FPC com fluxos completos de dependências e manutenção;
• publicação imutável com identidade de publishers;
• releases verificáveis para Windows e Linux.

Essas capacidades não são recursos isolados. Elas formam um caminho completo:

descobrir → resolver → baixar → verificar → instalar → auditar → atualizar

O objetivo é permitir que uma equipe saiba não apenas qual dependência utiliza,
mas qual versão foi selecionada, de onde veio, qual artefato foi instalado e
quais evidências de integridade acompanharam a operação.

Registry v2: descoberta sem baixar o catálogo inteiro

O Boss4D continua compatível com o índice público v1 e com os mapas tradicionais
do boss.json, mas agora também entende índices Registry v2.

O novo protocolo permite compor fontes:

{
  "schemaVersion": 2,
  "includes": [
    "index-v1.json"
  ],
  "sparse": [
    "packages/dext.json",
    "packages/horse.json"
  ]
}

Isso permite manter um catálogo legado, incluir outros índices e buscar
metadados individuais de um pacote. À medida que o catálogo cresce, a CLI não
precisa baixar novamente um arquivo único contendo todo o histórico.

Os comandos continuam simples:

boss4d registry list
boss4d registry add https://packages.exemplo.com/index-v2.json
boss4d search Dext
boss4d info Dext

O Registry v2 também introduz:

• cache persistente de metadados;
• operação offline;
• revalidação com ETag e Last-Modified;
• resposta HTTP 304 Not Modified;
• mirrors ordenados;
• prevenção de ciclos entre índices compostos;
• revogação explícita de versões.

Em uma execução online, o Boss4D reutiliza o cache quando o servidor informa que
o documento não mudou. Em modo offline, somente os metadados já disponíveis
localmente são utilizados:

boss4d search dext --offline
boss4d install --offline

Essa arquitetura reduz tráfego, melhora a disponibilidade e cria uma base para
registros públicos ou privados de maior escala.

Protocolo pronto não significa catálogo já povoado

O índice público atual possui 55 entradas de descoberta baseadas em repositórios
Git. O protocolo v2 e o suporte a pacotes sparse estão implementados, mas a
publicação progressiva de releases .b4dpkg assinadas ainda depende da adesão
dos mantenedores.

Essa distinção é importante: a infraestrutura está disponível, enquanto o
crescimento do catálogo é um trabalho contínuo de ecossistema.

Instalação de pacotes .b4dpkg com verificação completa

O formato .b4dpkg representa uma versão imutável de um pacote. Na versão
1.6.0, o Boss4D não apenas produz esse arquivo: ele consegue selecionar,
verificar e instalar o artefato adequado à plataforma e ao compilador.

Uma versão no Registry pode publicar variantes:

{
  "version": "1.2.0",
  "variants": [
    {
      "compiler": "37.0",
      "platform": "Win64",
      "artifact": "https://cdn.exemplo.com/pacote-1.2.0-d13-win64.b4dpkg",
      "sha256": "..."
    },
    {
      "compiler": "3.2.2",
      "platform": "linux",
      "artifact": "https://cdn.exemplo.com/pacote-1.2.0-fpc-linux.b4dpkg",
      "sha256": "..."
    }
  ]
}

Durante a instalação, o Boss4D:

1. seleciona deterministicamente a variante compatível;
2. tenta os mirrors na ordem declarada;
3. verifica o SHA-256 externo do artefato;
4. abre o pacote em uma área temporária;
5. valida os hashes internos de cada arquivo;
6. recusa caminhos que tentem escapar da raiz;
7. verifica assinatura OpenPGP quando exigida;
8. valida a proveniência in-toto;
9. promove a instalação somente após todas as verificações.

Se qualquer etapa falhar, o pacote não substitui o estado anterior.

Quando uma dependência ainda não possui artefato no Registry, o fluxo Git
continua disponível como fallback. Assim, a adoção do novo formato pode ocorrer
gradualmente, sem quebrar projetos existentes.

Mirrors e versões revogadas

Uma URL indisponível não deve tornar um pacote impossível de instalar. O
Registry v2 permite declarar mirrors de metadados e artefatos.

O Boss4D tenta as fontes na ordem definida e aceita um mirror somente quando o
conteúdo passa pelas mesmas verificações criptográficas. Um arquivo obtido de um
mirror não ganha confiança por ter sido baixado com sucesso; seu digest precisa
corresponder ao valor imutável publicado.

O protocolo também diferencia remoção e revogação. Uma versão publicada não é
sobrescrita. Quando ela não deve mais ser usada, o Registry registra a
revogação e seu motivo.

Isso preserva o histórico para auditoria e impede que a identidade
nome + versão passe a apontar silenciosamente para bytes diferentes.

Publicação segura e imutável

O comando publish foi ampliado para produzir o pacote, a proveniência e os
metadados necessários para o Registry:

boss4d publish --dry-run --output publish.json
boss4d publish --registry https://registry.exemplo.com

Antes de enviar qualquer conteúdo, o Boss4D verifica:

• existência e consistência do boss.json;
• lock schema v3;
• identidade idêntica entre manifesto e lock;
• revisões e checksums das dependências;
• estado do repositório Git;
• execução do script de testes, quando declarado;
• determinismo do pacote produzido.

O modo --dry-run não acessa a rede e permite inspecionar exatamente o que seria
publicado.

Tokens são obtidos da variável BOSS4D_PUBLISH_TOKEN, de outra variável
selecionada com --token-env ou do cofre nativo. No Linux, o Boss4D possui
integração com Secret Service. O token é enviado somente no cabeçalho de
autorização e nunca entra no manifesto, lock, URL Git ou payload.

O servidor deve rejeitar a tentativa de publicar novamente a mesma combinação
de nome e versão. O Boss4D trata HTTP 409 Conflict como proteção de
imutabilidade, não como uma oportunidade de sobrescrever a release anterior.

Publishers identificados e revisados

O Registry público agora possui um fluxo de onboarding de publishers.

Cada identidade autorizada pode declarar:

• nome;
• escopo de pacotes;
• fingerprint OpenPGP;
• estado da autorização.

As submissões passam por um workflow que verifica:

• se o publisher pode publicar naquele escopo;
• se o fingerprint corresponde ao cadastrado;
• se a versão é nova e imutável;
• se checksum, assinatura e proveniência estão presentes;
• se os metadados obedecem ao protocolo.

O repositório inclui um template de pacote e validações negativas para garantir
que uma submissão inválida seja realmente recusada.

Esse modelo mantém Git e pull requests como fonte de governança auditável,
enquanto artefatos e metadados podem ser servidos por infraestrutura HTTP ou
CDN.

CLI Linux: de host inicial a fluxo cotidiano

A evolução mais visível da versão 1.6.0 está na CLI Linux x86-64 compilada
nativamente com FPC 3.2.2.

Ela agora cobre:

• init;
• add, remove e list;
• install, ci, --locked, --frozen-lockfile e --offline;
• resolução SemVer highest e minimal;
• registry, search e info;
• instalação verificada de .b4dpkg;
• dependencies e tree;
• why;
• outdated;
• update e o alias upgrade;
• run;
• doctor;
• cache;
• workspaces;
• ferramentas globais;
• credenciais seguras;
• sbom;
• audit;
• pack;
• publish;
• self-update.

Exemplos:

boss4d install --frozen-lockfile
boss4d dependencies
boss4d why dext
boss4d outdated
boss4d update
boss4d run test

O comando update é transacional: uma falha restaura manifesto, lock e módulos.
Pacotes imutáveis já instalados pelo Registry são preservados corretamente
durante a atualização.

Workspaces utilizam links simbólicos, ferramentas globais FPC são compiladas e
instaladas em ~/.boss/bin, e o cache pode ser consultado ou limpo sem depender
do Registro do Windows.

As integrações específicas com RAD Studio, GetIt, GUI VCL e plugins da IDE
continuam naturalmente restritas ao Windows.

SBOM, VEX e auditoria também no Linux

A CLI FPC produz SBOMs determinísticos diretamente do lock:

boss4d sbom --format cyclonedx --lock-only
boss4d sbom --format spdx --lock-only

Os formatos suportados são:

• CycloneDX 1.7;
• SPDX 2.3.

CycloneDX pode receber um documento VEX offline, enquanto ambos os formatos
podem gerar e verificar atestações SHA-256 destacadas.

A auditoria consulta revisões travadas no OSV:

boss4d audit
boss4d audit --fail-on high
boss4d audit --offline

O cache permite repetir auditorias sem rede. Políticas de severidade produzem
códigos de saída estáveis para CI, e uma decisão VEX revisada pode informar que
uma vulnerabilidade conhecida não afeta determinado componente.

Com isso, inventário, vulnerabilidades e contexto de exploração fazem parte do
mesmo fluxo de dependências no Windows e no Linux.

Progresso e automação previsíveis

O Boss4D oferece quatro modos de progresso:

boss4d install --progress interactive
boss4d install --progress plain
boss4d install --json
boss4d install --quiet

O modo JSON Lines facilita integração com pipelines e coletores. Códigos de
saída diferenciam falhas de uso, rede, integridade, cache offline e políticas de
auditoria.

Também há cancelamento cooperativo por Ctrl+C, evitando abandonar uma
instalação em um estado intermediário.

Autoatualização transacional no Windows e Linux

No Windows:

boss4d self-update

A CLI baixa Boss4D_Setup.exe, verifica seu SHA-256 e somente então inicia o
instalador.

No Linux, o mesmo comando seleciona:

boss4d-linux-x86_64.tar.gz

O arquivo é comparado com SHA256SUMS.txt, extraído em staging e promovido com
backup e rollback. Se o download, checksum, extração ou substituição falhar, o
executável anterior permanece disponível.

Releases verificáveis para Windows e Linux

A versão 1.6.0 publica:

• Boss4D_Setup.exe;
• boss4d-windows.zip;
• boss4d-linux-x86_64.tar.gz;
• SHA256SUMS.txt;
• artifact-matrix.json;
• SBOM CycloneDX;
• SBOM SPDX;
• atestações in-toto dos SBOMs.

O arquivo artifact-matrix.json descreve de forma legível por máquina os
compiladores e plataformas cobertos.

No Windows, a matriz inclui CLI Win32/Win64 e plugins compilados com Delphi
10.1, 11, 12 e 13. No Linux, a CLI é compilada e executada em Ubuntu com FPC
3.2.2.

Antes da liberação foram executados:

• 143 testes DUnitX em Win32;
• 143 testes DUnitX em Win64;
• 61 testes FPCUnit em Linux;
• builds reais dos plugins Delphi 10.1, 11, 12 e 13;
• validadores oficiais CycloneDX e SPDX;
• testes de reprodutibilidade;
• validação dos workflows;
• SonarQube com quality gate aprovado e zero issues abertas.

Como instalar ou atualizar

No Windows, baixe o instalador na página da release:

Boss4D 1.6.0 no GitHub

Quem já utiliza uma versão compatível pode executar:

boss4d self-update

No Linux:

tar -xzf boss4d-linux-x86_64.tar.gz
chmod +x boss4d
./boss4d version

Antes de executar qualquer arquivo baixado manualmente, compare seu SHA-256 com
o conteúdo de SHA256SUMS.txt.

O que vem depois

Com Registry, pacotes verificáveis, Linux e conformidade estabelecidos, uma das
próximas fronteiras do Boss4D é ampliar a maturidade na compilação e instalação
de componentes em múltiplas versões do Delphi.

Isso envolve:

• builds isolados por compilador, plataforma e configuração;
• grafo de projetos runtime e design-time;
• rebuild incremental;
• paralelismo seguro;
• registro e desregistro transacional na IDE;
• diagnóstico de DCUs, BPLs e paths conflitantes.

Essa evolução permitirá reconstruir não apenas as dependências de um projeto,
mas todo o ambiente de componentes utilizado por uma equipe.

Conclusão

O Boss4D 1.6.0 transforma fundações técnicas em fluxos utilizáveis.

O Registry v2 reduz o custo de descoberta e prepara o catálogo para crescer.
Pacotes .b4dpkg verificáveis criam uma identidade imutável para cada release.
Mirrors aumentam disponibilidade sem reduzir as garantias de integridade.
Publishers revisados melhoram a governança. A CLI Linux passa a cobrir o ciclo
cotidiano de um projeto. SBOM, VEX, OSV e proveniência mantêm segurança e
auditoria como partes do processo, não como atividades posteriores.

Para projetos Delphi e Lazarus que precisam combinar produtividade,
reprodutibilidade e segurança da cadeia de fornecimento, a versão 1.6.0 é o
passo mais completo do Boss4D até agora.