Add OpenSslLegacyShim to ensure OpenSSL 1.1 libraries are accessible on Linux
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled

This commit introduces the OpenSslLegacyShim class, which sets the LD_LIBRARY_PATH environment variable to include the directory containing OpenSSL 1.1 native libraries. This is necessary for Mongo2Go to function correctly on Linux platforms that do not ship these libraries by default. The shim checks if the current operating system is Linux and whether the required directory exists before modifying the environment variable.
This commit is contained in:
master
2025-11-02 21:41:03 +02:00
parent f98cea3bcf
commit 1d962ee6fc
71 changed files with 3675 additions and 1255 deletions

View File

@@ -0,0 +1,32 @@
# Python Ecosystem
## StellaOps implementation
- `src/Scanner/__Libraries/StellaOps.Scanner.Analyzers.Lang.Python/PythonLanguageAnalyzer.cs` enumerates `*.dist-info` directories (using deterministic traversal options) and loads metadata through `PythonDistributionLoader`.
- Components are emitted only when authoritative installed metadata is available (`METADATA`, `RECORD`, `entry_points.txt`), guaranteeing observed-state accuracy across layers and virtual environments.
- EntryTrace usage hints flag distributions whose scripts appear in runtime paths, enabling “usage vs inventory” SBOM differentiation.
- Evidence payloads capture file locators (path + hash) so downstream diff/attestation pipelines can replay findings deterministically.
## Trivy implementation
- Multiple analyzers under `pkg/fanal/analyzer/language/python` target packaging formats (`packaging`, `egg`, `wheel`) and lockfiles (`pip`, `poetry`, `pipenv`, `uv`).
- Lockfile analyzers parse dependency graphs via language parsers (e.g., `pkg/dependency/parser/python/poetry`), classifying direct vs transitive packages for vulnerability matching.
- Packaging analyzers walk archives to populate `types.Application`, enriching license data by inspecting declared license files.
- Outputs prioritise dependency relationships; runtime usage and per-file evidence are not tracked.
## Snyk implementation
- The CLI selects `snyk-python-plugin` for `pip` and `poetry` projects (`src/lib/plugins/index.ts`).[s1]
- Users must authenticate and often build or prepare their Python environment before running `snyk test`; dependency graphs are uploaded to Snyks SaaS backend for analysis.[s2]
- No runtime usage metadata or per-file evidence is surfaced beyond the API response.
## Grype implementation
- SBOM extraction relies on Syft (`grype/pkg/syft_provider.go`), which catalogs Python packages from `dist-info`/egg metadata.
- The Python matcher accepts `syftPkg.PythonPkg` entries and performs ecosystem/CPE matching via Anchores provider (`grype/matcher/python/matcher.go`).
- No runtime or usage annotations beyond Syfts inventory; lockfile vs installed distinctions follow Syfts behavior.
## Key differences
- **Source of truth**: StellaOps confines itself to installed artefacts for determinism; Trivy, Snyk, and Grype accommodate SBOM/lockfile inventory generated by their parsers.
- **Usage metadata**: StellaOps propagates EntryTrace usage, supporting policy decisions on runtime reach; Trivy, Snyk, and Grype emit inventory without runtime context.
- **Evidence granularity**: StellaOps stores per-file evidence hashes; Trivy, Snyk, and Grype focus on dependency graphs and CPE matching, not replay artefacts.
### References
- [s1] `/tmp/snyk-cli/src/lib/plugins/index.ts`
- [s2] `/tmp/snyk-cli/README.md`