Skip to content

fix(detector): find Eclipse plugins in the macOS p2 shared bundle pool - #189

Open
rksharma95 wants to merge 1 commit into
step-security:mainfrom
rksharma95:rk/eclipse-macos-p2-pool-features
Open

fix(detector): find Eclipse plugins in the macOS p2 shared bundle pool#189
rksharma95 wants to merge 1 commit into
step-security:mainfrom
rksharma95:rk/eclipse-macos-p2-pool-features

Conversation

@rksharma95

Copy link
Copy Markdown

Installs created by the Eclipse Installer keep their units in a shared p2 bundle pool rather than under the app bundle: features/ is absent and plugins/ holds only the launcher jar. macOS detection only ever looked at /Contents/Eclipse/{features,dropins}, so every plugin on such an install went unreported — verified on a real 4.41.0 install where 0 were detected while 12 third-party features (Amazon Q, Spring Tools, DBeaver, PMD) were present.

  • scan /features alongside the install-local features/, resolving the pool from eclipse.p2.data.area in configuration/config.ini (a Java properties value with escaped colons) and falling back to ~/.p2/pool
  • report feature groups only: one entry per installed product rather than the dozens of OSGi bundles it ships (parsing bundles.info instead yielded 147 records for the same 12 products, mostly DBeaver internals)
  • route dropins through collectDropins so nested /eclipse/plugins layouts are picked up and the source is tagged "dropins" rather than mislabelled "user_installed"
  • dedupe on id@version since a feature can be present both install-locally and in the pool
  • tests: pool layout, self-contained layout, pool resolution from config.ini and the ~/.p2/pool fallback, no-pool, no-install, and cross-source dedup

What does this PR do?

Type of change

  • Bug fix
  • Enhancement
  • Documentation

Testing

  • Tested on macOS (version: ___)
  • Binary runs without errors: ./stepsecurity-dev-machine-guard --verbose
  • JSON output is valid: ./stepsecurity-dev-machine-guard --json | python3 -m json.tool
  • No secrets or credentials included
  • Lint passes: make lint
  • Tests pass: make test

Related Issues

Installs created by the Eclipse Installer keep their units in a shared p2
bundle pool rather than under the app bundle: features/ is absent and
plugins/ holds only the launcher jar. macOS detection only ever looked at
<app>/Contents/Eclipse/{features,dropins}, so every plugin on such an
install went unreported — verified on a real 4.41.0 install where 0 were
detected while 12 third-party features (Amazon Q, Spring Tools, DBeaver,
PMD) were present.

- scan <pool>/features alongside the install-local features/, resolving the
  pool from eclipse.p2.data.area in configuration/config.ini (a Java
  properties value with escaped colons) and falling back to ~/.p2/pool
- report feature groups only: one entry per installed product rather than
  the dozens of OSGi bundles it ships (parsing bundles.info instead yielded
  147 records for the same 12 products, mostly DBeaver internals)
- route dropins through collectDropins so nested <feature>/eclipse/plugins
  layouts are picked up and the source is tagged "dropins" rather than
  mislabelled "user_installed"
- dedupe on id@version since a feature can be present both install-locally
  and in the pool
- tests: pool layout, self-contained layout, pool resolution from
  config.ini and the ~/.p2/pool fallback, no-pool, no-install, and
  cross-source dedup

Signed-off-by: rksharma95 <ramakant@stepsecurity.io>
Comment thread internal/detector/eclipse_plugins.go
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants