Desde a versão 1.2.0, o Boss4D passou por uma evolução importante. O projeto deixou de atuar apenas como instalador de dependências e tornou-se uma plataforma mais completa de gerenciamento, automação, auditoria e rastreabilidade para projetos Delphi e Lazarus.

As versões 1.2.0, 1.2.1, 1.3.0 e 1.4.0 trouxeram melhorias em quatro áreas principais:

• Builds determinísticos e integração com Delphi e Lazarus.
• Gerenciamento transacional e reproduzível de dependências.
• Segurança, auditoria e conformidade da cadeia de suprimentos.
• Produtividade por meio de registries, cache e templates de projetos.

Neste artigo, veremos o que mudou e como esses recursos ajudam equipes que precisam de builds confiáveis, automação de CI e evidências técnicas sobre os componentes utilizados em suas aplicações.

Boss4D 1.2.0: builds previsíveis e suporte ao Lazarus

A versão 1.2.0 concentrou-se em tornar a instalação e a compilação de pacotes mais determinísticas.

Armazenamento de dependências sem colisões

Dependências com nomes semelhantes ou originadas de repositórios diferentes passaram a ser armazenadas usando sua identidade canônica.

Isso evita que dois pacotes sobrescrevam o mesmo diretório dentro de modules/ e permite que o lock e o SBOM mantenham uma referência inequívoca à origem de cada componente.

Precedência da toolchain

O Boss4D passou a determinar a toolchain efetiva de forma previsível, considerando as configurações do projeto e do ambiente.

Também foi implementada a compilação ordenada dos projetos declarados pelo pacote. Isso é especialmente importante quando uma dependência contém mais de um .dproj, .lpi ou .lpk e existe uma ordem necessária entre eles.

Compilação de projetos Lazarus

Projetos Lazarus declarados no manifesto passaram a ser encaminhados nativamente ao lazbuild.

O Boss4D consegue identificar e compilar:

.lpi
.lpk

Com isso, um mesmo grafo de dependências pode conter bibliotecas Delphi e Lazarus.

Templates iniciais

A versão também introduziu os primeiros templates protegidos:

boss4d new app MeuProjeto
boss4d new package MinhaBiblioteca

O Boss4D recusa-se a sobrescrever um diretório que já contenha arquivos. Isso reduz o risco de destruir acidentalmente um projeto existente.

Normalização determinística

Antes da geração de checksums e evidências para SBOM, arquivos de texto passaram por uma normalização determinística de finais de linha.

Essa medida evita que o mesmo conteúdo produza checksums diferentes apenas por ter sido manipulado em ambientes com convenções distintas de quebra de linha.

Preservação de arquivos DPK

A atualização da cláusula requires em pacotes Delphi passou a preservar:

• Diretivas condicionais.
• Comentários de final de linha.
• Espaçamento existente.
• Múltiplos blocos requires.

A integração tornou-se menos invasiva para pacotes que possuem configurações específicas por plataforma ou versão do compilador.

Boss4D 1.2.1: integração mais cuidadosa com o RAD Studio

A versão 1.2.1 complementou o trabalho iniciado na 1.2.0.

A integração com o RAD Studio passou a considerar os caminhos de depuração, ou browsingpath, dos pacotes instalados. Isso melhora a navegação pelo código-fonte das dependências durante o desenvolvimento e a depuração.

Também foram corrigidos casos adicionais na manipulação de arquivos DPK, especialmente aqueles que combinavam comentários, múltiplos blocos e diretivas condicionais.

Boss4D 1.3.0: integração automática com projetos Lazarus

Na versão 1.3.0, o suporte ao Lazarus avançou além da compilação.

O Boss4D passou a integrar automaticamente os caminhos das dependências em:

• Projetos Lazarus .lpi.
• Pacotes Lazarus .lpk.
• Todos os modos de build declarados no projeto.

Os caminhos são adicionados de maneira determinística em OtherUnitFiles. Isso reduz a necessidade de configurar manualmente cada dependência na IDE e aproxima a experiência Lazarus daquela já oferecida aos projetos Delphi.

Boss4D 1.4.0: um novo ciclo de vida para dependências

A versão 1.4.0 é a maior atualização desse período. Ela amplia o Boss4D em praticamente todas as etapas do ciclo de vida de um pacote.

Operações transacionais

O Boss4D agora possui comandos explícitos para alteração e consulta do grafo:

boss4d add github.com/hashload/horse@^3.1.0
boss4d update horse
boss4d remove horse
boss4d list
boss4d why horse

Antes de uma operação que possa alterar o projeto, o Boss4D cria um snapshot de:

• boss.json.
• boss-lock.json.
• Diretório modules/.

Se ocorrer uma falha de resolução, checkout, checksum ou compilação, o estado anterior é restaurado automaticamente.

Isso evita que uma instalação interrompida deixe manifesto, lock e arquivos instalados em estados diferentes.

Remoção de dependências órfãs

Ao remover um pacote, o Boss4D percorre o grafo e identifica dependências transitivas que não são mais alcançáveis.

Uma dependência compartilhada por dois pacotes é preservada enquanto ainda estiver em uso. Somente os componentes efetivamente órfãos são removidos do lock e de modules/.

Entendendo o grafo

O comando list diferencia dependências diretas e transitivas:

boss4d list

Já o comando why mostra o caminho que levou um pacote a ser instalado:

boss4d why minha-dependencia

Esses comandos ajudam a responder perguntas importantes durante uma auditoria:

• Essa dependência foi declarada diretamente?
• Qual pacote introduziu esse componente?
• Ela é necessária em produção?
• Posso removê-la com segurança?

Instalações congeladas, offline e para CI

A versão 1.4.0 introduziu modos voltados a ambientes controlados:

boss4d install --locked
boss4d install --frozen-lockfile
boss4d install --locked --offline
boss4d ci
boss4d ci --offline

Lock congelado

--locked e --frozen-lockfile instalam exatamente o grafo registrado no boss-lock.json.

Nesses modos, o Boss4D:

• Valida se o manifesto corresponde ao lock.
• Usa as revisões Git registradas.
• Verifica os checksums SHA-256.
• Não regrava o lock.
• Interrompe a instalação caso exista divergência.

Modo offline

Com --offline, clones e atualizações remotas são desativados. Todas as dependências precisam estar disponíveis no cache local.

Esse modo é útil para:

• Builds isolados.
• Ambientes com acesso restrito à internet.
• Recuperação de versões antigas.
• Pipelines que separam aquisição e compilação.

Comando boss4d ci

O comando ci remove a árvore instalada e a reconstrói usando exclusivamente o lock congelado:

boss4d ci

Como a operação também é transacional, uma falha restaura o estado anterior do projeto.

Dependências de desenvolvimento e produção

O manifesto agora pode separar dependências de execução e desenvolvimento:

{
  "dependencies": {
    "github.com/hashload/horse": "^3.1.0"
  },
  "devDependencies": {
    "github.com/VSoftTechnologies/DUnitX": "^3.0.0"
  }
}

Uma dependência pode ser adicionada ao escopo de desenvolvimento com:

boss4d add github.com/VSoftTechnologies/DUnitX@^3.0.0 --dev

Para instalar somente o necessário em produção:

boss4d install --production

O escopo também é registrado no lock e transportado para documentos CycloneDX e SPDX. Assim, ferramentas externas conseguem distinguir componentes de runtime daqueles utilizados apenas em testes ou desenvolvimento.

boss-lock.json schema v3

Para suportar os novos fluxos, o lock evoluiu para o schema v3.

Ele mantém evidências como:

• Identidade canônica do repositório.
• Versão resolvida.
• Revisão Git imutável.
• Checksum SHA-256.
• Dependências diretas e transitivas.
• Escopo de runtime ou desenvolvimento.
• Metadados do componente raiz.
• Artefatos compilados declarados.

O lock deixa de ser apenas um registro de versões e passa a funcionar como uma fonte estruturada de evidências da instalação.

Auditoria de vulnerabilidades com OSV

O novo comando audit consulta vulnerabilidades usando a revisão registrada no lock:

boss4d audit

A consulta por commit é mais precisa do que depender somente de uma versão textual, principalmente em projetos que utilizam tags personalizadas ou referências Git.

Também foram adicionados:

• Cache local das respostas.
• Auditoria offline.
• Políticas de severidade.
• Falha controlada do pipeline.
• Supressão baseada em VEX.

Um pipeline pode, por exemplo, ser interrompido quando encontrar uma vulnerabilidade acima da severidade aceita pelo projeto.

VEX: contexto para vulnerabilidades conhecidas

Uma SBOM informa quais componentes estão presentes. Ela não diz necessariamente se uma vulnerabilidade é explorável naquela aplicação.

O VEX — Vulnerability Exploitability eXchange — complementa essa informação, permitindo registrar estados como:

• Afetado.
• Não afetado.
• Corrigido.
• Em análise.

O Boss4D pode usar um documento VEX offline tanto para enriquecer o CycloneDX quanto para tratar exceções durante a auditoria.

Isso evita que vulnerabilidades já avaliadas pela equipe precisem ser ignoradas informalmente ou removidas dos relatórios.

Políticas de confiança para Git

O manifesto pode exigir validações adicionais antes do checkout de uma dependência:

• Commits assinados.
• Tags assinadas.
• Lista de signatários permitidos.

Assim, uma versão semanticamente válida não é suficiente quando o projeto exige uma origem autenticada.

A verificação acontece antes que o conteúdo seja promovido para a árvore instalada.

Registries configuráveis e descoberta de pacotes

O Boss4D passou a trabalhar com índices locais ou HTTP:

boss4d registry add https://registry.example/index.json
boss4d registry list
boss4d search horse
boss4d info horse

Esses índices podem representar catálogos públicos ou privados.

A descoberta de pacotes é compartilhada entre:

• CLI.
• Interface gráfica.
• Integração com o RAD Studio.

Esse modelo permite que uma empresa mantenha um catálogo interno sem incorporar credenciais ou informações privadas ao manifesto do projeto.

GitHub Dependency Submission

O grafo registrado no lock pode ser enviado ao GitHub Dependency Graph:

boss4d dependency submit

O snapshot inclui:

• Dependências diretas.
• Dependências transitivas.
• Versões resolvidas.
• Escopos de runtime e desenvolvimento.

Com isso, projetos Delphi podem fornecer ao GitHub uma visão estruturada de suas dependências mesmo quando o ecossistema não é reconhecido automaticamente pelas ferramentas convencionais da plataforma.

Cache mais seguro

A estratégia de cache também foi aprimorada.

O Boss4D pode reutilizar objetos Git sem criar hardlinks de arquivos de trabalho entre o cache e a instalação. Isso impede que alterações em uma cópia contaminem outra.

Artefatos executáveis compilados são armazenados considerando:

• Checksum do código-fonte.
• Plataforma.
• Versão do compilador.

Um executável gerado para Win32 no Delphi 13, por exemplo, não é reutilizado indevidamente em um build Win64 ou em outra versão do compilador.

Novos templates de projetos

O comando new passou a oferecer uma coleção mais completa:

Exemplo:

boss4d new api MinhaAPI

O template de API já inclui Horse e Dext, enquanto o template DUnitX cria um runner e uma fixture inicial.

Todos os templates geram um boss.json coerente e recusam sobrescrever diretórios não vazios.

Publicação com validações obrigatórias

O comando publish gera um registro determinístico usando o manifesto e o lock:

boss4d publish --dry-run --output publish.json

O dry-run não realiza chamadas de rede. Ele permite revisar exatamente o conteúdo que seria enviado ao registry.

Antes da publicação real, o Boss4D valida:

• Presença do manifesto e do lock.
• Correspondência da identidade do pacote.
• Uso do schema v3.
• Revisão e checksum das dependências.
• Estado limpo do repositório Git.
• Execução do script de testes, quando declarado.

A publicação real utiliza um token obtido por variável de ambiente:

set BOSS4D_PUBLISH_TOKEN=seu-token
boss4d publish --registry https://registry.example/api

O token não é gravado no manifesto, no lock nem no payload publicado.

SBOM, SPDX, CycloneDX e atestações

O suporte de conformidade recebeu várias melhorias ao longo dessas versões.

O Boss4D gera:

• CycloneDX 1.7.
• SPDX 2.3.
• VEX em documentos CycloneDX.
• Atestações destacadas no formato in-toto.
• Checksums SHA-256.
• SBOM reproduzível baseada somente no lock.
• Inventário opcional do GetIt.
• Informações da toolchain e RTL do Delphi.
• Evidências de artefatos compilados.

Exemplo de geração para release:

boss4d sbom ^
  --format cyclonedx ^
  --lock-only ^
  --reproducible ^
  --strict ^
  --validate ^
  --output boss4d.cdx.json ^
  --attestation-output boss4d.cdx.intoto.json

Também é possível gerar SPDX:

boss4d sbom ^
  --format spdx ^
  --lock-only ^
  --reproducible ^
  --strict ^
  --validate ^
  --output boss4d.spdx.json

A geração reproduzível garante que o mesmo lock produza o mesmo documento, independentemente de a execução acontecer em Win32 ou Win64.

Qualidade e validação da versão

A versão 1.4.0 foi liberada depois de passar pelos seguintes gates:

• 100 testes DUnitX em Win32.
• 100 testes DUnitX em Win64.
• Compilação da CLI em Win32 e Win64.
• Compilação da interface gráfica em Win32 e Win64.
• Compilação do plugin para Delphi 11, 12 e 13.
• Validação externa dos documentos CycloneDX e SPDX.
• Verificação de reprodutibilidade entre arquiteturas.
• Geração e verificação das atestações.
• SonarQube Quality Gate aprovado.
• Instalador produzido pelo Inno Setup.
• Publicação de checksums SHA-256 dos artefatos.

Uma cadeia integrada de desenvolvimento e conformidade

A principal mudança desde a versão 1.2.0 não é apenas o aumento na quantidade de comandos.

O Boss4D passou a conectar etapas que normalmente ficam separadas:

manifesto
   ↓
resolução do grafo
   ↓
lock com evidências
   ↓
instalação reproduzível
   ↓
compilação Delphi/Lazarus
   ↓
auditoria de vulnerabilidades
   ↓
SBOM e atestação
   ↓
publicação

Essa integração permite tratar dependências Delphi e Lazarus com controles semelhantes aos encontrados em ecossistemas mais recentes, sem abandonar os formatos e ferramentas já utilizados nos projetos.

Como experimentar

A versão mais recente, o instalador, os checksums e os documentos de conformidade estão disponíveis na página oficial da release:

Baixar o Boss4D 1.4.0

O código-fonte e a documentação completa podem ser encontrados no GitHub:

Repositório do Boss4D

Se você trabalha com Delphi ou Lazarus e precisa de builds reproduzíveis, rastreabilidade de dependências e geração de SBOM, a versão 1.4.0 representa um excelente momento para experimentar o Boss4D.