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:
| Template | Projeto criado |
|---|---|
app | Aplicação console Delphi |
package | Biblioteca ou pacote reutilizável |
vcl | Aplicação VCL |
fmx | Aplicação FireMonkey |
api | API usando Horse e Dext |
horse-api | API usando Horse e Dext |
dext-api | API usando Horse e Dext |
dunitx | Projeto de testes DUnitX |
lazarus-app | Aplicação Lazarus |
lazarus-package | Pacote Lazarus |
workspace | Monorepo com aplicações e pacotes |
Deslize a tabela para os lados para ver todas as colunas.
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:
O código-fonte e a documentação completa podem ser encontrados no GitHub:
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.
0 comentário(s)