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,31 @@
# Go Modules & Binaries
## StellaOps implementation
- `src/Scanner/__Libraries/StellaOps.Scanner.Analyzers.Lang.Go/GoLanguageAnalyzer.cs` scans executables for Go build info (`module.Version`, `build Settings`) and reads DWARF metadata when available.
- Captures full module graphs (main + dependencies) with PURLs; for stripped binaries, falls back to hashed component keys via `GoBinaryScanner.TryClassifyStrippedBinary`.
- Metadata records Go toolchain settings, build IDs, and replacements; evidence references binary paths and entrypoint usage (`LanguageAnalyzerContext.UsageHints`).
- Ensures deterministic ordering and retains hashed fallback components for binaries lacking Go metadata.
## Trivy implementation
- Analyzer registry includes `pkg/fanal/analyzer/language/golang/binary/binary.go` (Go binaries) and `.../mod/mod.go` (`go.mod` + `go.sum`).
- Binary parser utilises `pkg/dependency/parser/golang/binary` to extract module data; non-Go or unrecognised binaries return nil without fallback components.
- Module analyzer parses dependency requirements and classifies direct vs indirect modules but does not capture runtime usage or binary hashes.
## Snyk implementation
- `src/lib/plugins/index.ts` dispatches Go projects to `snyk-go-plugin` (golangdep, gomodules, govendor).[s1]
- CLI scans require authenticated connectivity and send dependency graphs to Snyks SaaS backend (`snyk test`, `snyk monitor`) for analysis; binaries are not inspected locally.[s2]
- No fallback hashing or runtime usage metadata accompanies the results.
## Grype implementation
- SBOM generation via Syft feeds Go modules/binaries into Grype (`grype/pkg/syft_provider.go`).
- The Go matcher consumes `syftPkg.GoModulePkg`, applying ecosystem+/-CPE logic and skipping binaries with pseudo-version metadata when build info is insufficient (`grype/matcher/golang/matcher.go`).
- No fallback hashing beyond Syfts catalog; runtime usage and DWARF metadata are not surfaced.
## Key differences
- **Fallback handling**: StellaOps emits explicit hashed components when build info is missing; Trivy and Grype skip binaries without usable metadata.
- **Runtime linkage**: StellaOps ties modules to binary paths and EntryTrace usage; Trivy, Snyk, and Grype output inventory without execution context.
- **Build metadata**: StellaOps records DWARF/VCS settings; Trivy, Snyk, and Grype rely on module info exposed by their parsers without extended metadata.
### References
- [s1] `/tmp/snyk-cli/src/lib/plugins/index.ts`
- [s2] `/tmp/snyk-cli/README.md`