Renamed packages
The per-ecosystem naming pattern Seal uses when a sealed package is renamed.
Last updated
The per-ecosystem naming pattern Seal uses when a sealed package is renamed.
When Package renaming is enabled (via --use-sealed-names on the CLI or SEAL_USE_SEALED_NAMES=true in the environment), the Seal CLI installs sealed packages under a prefixed name.
The table below uses $version for the origin version, $name for the package name, $X for the iteration number, and $REV for the Alpine revision (see Alpine note below).
Java
seal.sp$X.$groupId:$artifactId
$version (the +sp$X moves into the groupId; +sp999 may be added as a sentinel in fixed events)
JavaScript
@seal-security/$name
$version-sp$X
JavaScript (scoped)
@seal-security/$seal-$name
$version-sp$X
Python
seal-$name
$version+sp$X
Go
sealsecurity.io/$name
$version-sp$X
Ruby
seal-$name
$version.0.1.sp$X
Debian
seal-$name
$version+sp$X
RPM
seal-$name
$version+sp$X
Alpine
seal-$name
$version-r$REV (see Alpine note)
Alpine. Alpine does not append an sp suffix to the version. Sealed iterations advance through the package-revision field (r$REV) by prepending zeros to the original revision: an origin at 8.45-r3 produces sealed iterations 8.45-r03, 8.45-r003, 8.45-r0003, and so on. Renaming changes the package name to seal-$name; the version pattern is unchanged from the per-ecosystem versioning table.
Last updated