Files
syft/syft/pkg/language.go
T
Alex Goodman 8d5567c423 feat: catalog CPAN distributions installed by perl clients (#5131)
* feat: catalog CPAN distributions installed by perl clients

Adds `perl` as a language and `cpan` as a package type, with two catalogers behind them.

- `perl-cpan-installed-cataloger` reads `.meta/*/install.json` (cpanm, cpm, carton) and `auto/**/.packlist` (anything installed through `ExtUtils::MakeMaker` or `Module::Build`, including CPAN.pm). Both globs are unanchored, so a local-lib or carton application tree is found the same as a system install.
- `perl-cpan-meta-cataloger` reads an unpacked release's own `META.json` or `META.yml`, gated on a sibling `MANIFEST` so source checkouts are ignored.

Packages are keyed on the **distribution**, not the module, because that is what CPAN, MetaCPAN and the advisory data all use. `LWP.pm` belongs to `libwww-perl` and reporting it as `LWP` would make every advisory for it unreachable. The distribution name comes from `install.json`'s `dist` field, and from the `auto/` path for packlists.

purls are `pkg:cpan/<distribution>@<version>`, with the PAUSE author added as an `author` qualifier when the evidence carries it. Metadata comes in two types: `cpan-distribution` for installed evidence and `cpan-unpacked-release` for a release sitting on disk. The tiers differ in more than a name, so a consumer should not have to string-match a cataloger name to tell them apart: an unpacked release has no PAUSE path and therefore no author and no file list, and "installed and loadable by the interpreter" is a materially stronger claim than "a source tree exists here".

A packlist's version comes from `perllocal.pod`. EUMM writes it and the packlist from the same variables in the same install target, so the `auto/` path segments and the perllocal `Module` name are the same key, and the recorded `VERSION` is what was evaluated at build time rather than what can be read back statically. Scraping `$VERSION` out of the main `.pm` is the fallback, since `NO_PERLLOCAL` suppresses the file and Module::Build never writes one. Three rules pick the stanza: dashed module name, longest `installed into` libdir that prefixes the packlist path, and last match wins because the file is append-only. Without the libdir rule a second perl on the image silently supplies the version.

Where scraping is the fallback, it reads more than a plain `our $VERSION = '...'`. A version declared in the package statement (`package Foo::Bar v1.0.0;`) counts, which matters because a distribution can declare it that way and carry no `$VERSION` at all: `CPAN::02Packages::Search` is one, and without this it reports no version and matches nothing. Fully qualified `$Foo::Bar::VERSION` counts too, which is what older Dist::Zilla emitted and what real `JSON::PP` 2.27300 still carries. `qv('1.2.3')` is handled. A version computed at runtime is not, and those are reported without one rather than guessed at.

Packlist entries are parsed the way `ExtUtils::Packlist` writes them: a line can carry space-separated metadata after the path (`/path/to/File.pm type=file`), which is what `installperl` produces, so the suffix is stripped rather than the line being cut at its first space.

`META.yml` is read alongside `META.json`, because about 43% of current CPAN releases ship no `META.json` and they skew old, which is where the advisories are. Where both sit in one directory the `META.json` wins. A `META.yml` a strict parser rejects skips that directory rather than failing the scan, which is routine rather than defensive for pre-spec releases.

A packlist is literally a file list, so its paths are surfaced through `pkg.FileOwner`. They are reported as recorded, unfiltered: a path the packlist claims and the filesystem lacks means the file was removed or overwritten out from under the installer, which is worth seeing rather than hiding.

Build leftovers under `~/.cpanm/work` and `~/.cpan/build` are skipped. They genuinely are unpacked release tarballs, `MANIFEST` included, so the `MANIFEST` gate admits them and a path exclusion is the only signal available. Without it every distribution on an image that did not clean up is reported twice. The cost is that a tarball deliberately kept under `~/.cpan/build` stops being reported.

Two behaviors that look wrong but are not:

- a distribution can be reported twice at different versions. `libwww-perl` 5.836 bundles `HTTP-Date`, `HTTP-Message` and `LWP-MediaTypes`, and installing it over the modern standalone releases overwrites their `.pm` files. Both versions are genuinely present, so the merge refuses to pair disagreeing versions rather than hiding one.
- a distribution with no readable version is reported without one rather than dropped, so it stays visible.

The coverage boundary is stated in full in the `package perl` doc comment. In short: modules installed from distro packages are out of scope, since packagers strip CPAN metadata with `NO_PACKLIST` and deb, rpm and apk already report them. Core and dual-life distributions bundled with the interpreter have no coverage, because nothing on disk carries their versions; the interpreter itself is reported separately. Vendored trees, `App::FatPacker` output and PAR archives are invisible, because what they carry is module identity with no offline map to a distribution. A packlist-derived name is the installer's `NAME` and may not be the distribution name, which is left to the vulnerability data to resolve.

One correction worth calling out, since it is easy to arrive at twice: a sibling `MANIFEST` is the only thing separating an unpacked release from a source checkout. An earlier version of the guard also rejected any tree containing a `dist.ini`, on the theory that it marked a Dist::Zilla source tree. dzil ships `dist.ini` *inside* the tarballs it builds and lists it in the generated `MANIFEST`, so that exclusion was silently skipping real releases, `URI` among them.

Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>

* test(cli): bump coverage image package count for the new perl fixture

The CPAN fixture added to `image-pkg-coverage` (`URI-5.35`) is shared with the CLI suite through a symlink, so the squashed package count goes from 42 to 43.

Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>

* fix(perl): take CPAN distribution name and version from install.json dist

cpanm writes the main module's `$VERSION` into `version` and the release distvname into `dist`, and the two often disagree (`Carp-Assert-More-2.9.0` records `2.009000`). Trimming `version` off `dist` failed on those, so the whole distvname became the package name, and the module version never paired with the packlist record for the same install, which reported the distribution twice.

- name and version are now split out of `dist` at the last `-` followed by a version, as CPAN::DistnameInfo does
- a `-TRIAL` suffix is dropped, so `Try-Tiny-0.26-TRIAL` reports as `Try-Tiny` `0.26`
- the PAUSE path fallback uses the same split

Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>

---------

Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>
2026-09-30 14:15:05 -04:00

119 lines
3.1 KiB
Go

package pkg
import (
"strings"
"github.com/anchore/packageurl-go"
)
// Language represents a single programming language.
type Language string
const (
// the full set of supported programming languages
UnknownLanguage Language = ""
CPP Language = "c++"
Dart Language = "dart"
Dotnet Language = "dotnet"
Elixir Language = "elixir"
Erlang Language = "erlang"
Go Language = "go"
Haskell Language = "haskell"
Java Language = "java"
JavaScript Language = "javascript"
Lua Language = "lua"
OCaml Language = "ocaml"
Perl Language = "perl"
PHP Language = "php"
Python Language = "python"
R Language = "R"
Ruby Language = "ruby"
Rust Language = "rust"
Swift Language = "swift"
Swipl Language = "swipl"
)
// AllLanguages is a set of all programming languages detected by syft.
var AllLanguages = []Language{
CPP,
Dart,
Dotnet,
Elixir,
Erlang,
Go,
Haskell,
Java,
JavaScript,
Lua,
OCaml,
Perl,
PHP,
Python,
R,
Ruby,
Rust,
Swift,
Swipl,
}
// String returns the string representation of the language.
func (l Language) String() string {
return string(l)
}
func LanguageFromPURL(p string) Language {
purl, err := packageurl.FromString(p)
if err != nil {
return UnknownLanguage
}
return LanguageByName(purl.Type)
}
func LanguageByName(name string) Language {
switch strings.ToLower(name) {
case packageurl.TypeMaven, string(purlGradlePkgType), string(JavaPkg), string(Java):
return Java
case packageurl.TypeComposer, string(PhpComposerPkg), string(PHP):
return PHP
case packageurl.TypeGolang, string(GoModulePkg), string(Go):
return Go
case packageurl.TypeNPM, string(JavaScript), "nodejs", "node.js":
return JavaScript
case packageurl.TypeLuaRocks, string(Lua):
return Lua
// note: packageurl.TypeCpan and CpanPkg are the same string, so only one can be listed here
case packageurl.TypeCpan, string(Perl):
return Perl
case packageurl.TypePyPi, string(Python):
return Python
case packageurl.TypeGem, string(Ruby):
return Ruby
case purlCargoPkgType, string(RustPkg), string(Rust):
return Rust
case packageurl.TypePub, string(DartPubPkg), string(Dart):
return Dart
case string(Dotnet), ".net", packageurl.TypeNuget:
return Dotnet
case packageurl.TypeCocoapods, packageurl.TypeSwift, string(CocoapodsPkg):
return Swift
case "swipl", string(SwiplPackPkg):
return Swipl
case "ocaml", string(OpamPkg):
return OCaml
case packageurl.TypeConan, string(CPP):
return CPP
case packageurl.TypeHackage, string(Haskell):
return Haskell
case packageurl.TypeHex, packageurl.TypeOTP, "beam", "elixir", "erlang":
// should we support returning multiple languages to support this case?
// answer: no. We want this to definitively answer "which language does this package represent?"
// which might not be possible in all cases. See for more context: https://github.com/package-url/purl-spec/pull/178
return UnknownLanguage
case packageurl.TypeCran, "r":
return R
default:
return UnknownLanguage
}
}