This is an automated email from the ASF dual-hosted git repository. oscerd pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/camel-karaf.git
commit ff6dacd73ccbc54fb9982c4e4926695dae7e8f05 Author: Andrea Cosentino <[email protected]> AuthorDate: Fri May 15 18:44:57 2026 +0200 docs: add camel-karaf security model, SECURITY.md and AGENTS.md Adds a Karaf-specific threat model documenting who is trusted, where the trust boundaries sit, and what counts as a camel-karaf vulnerability versus an Apache Camel core or operator responsibility. camel-karaf is a runtime adapter: the data-plane vulnerability classes (deserialization, XXE, injection, path traversal, header abuse, ...) live in Apache Camel core and components. This model therefore defers those to the canonical Apache Camel Security Model and covers only the Karaf delta: the camel-core-osgi resolution layer, the Blueprint DSL trust position, the Karaf shell as a management surface, the feature / Pax-URL install model, and "OSGi is not a security sandbox". The model is fully ratified; provenance tags are retained as the chain of authority for triage. - docs/modules/ROOT/pages/security-model.adoc: the threat model, mirroring the apache/camel security-model.adoc house style - docs/modules/ROOT/nav.adoc: link the new page in the user guide nav - SECURITY.md: GitHub-rendered reporting pointer to the model and the Apache Camel private disclosure process - AGENTS.md (+ CLAUDE.md symlink): AI-agent guidelines incl. a Security Model summary, matching the apache/camel AGENTS.md style Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> --- AGENTS.md | 358 ++++++++++++++ CLAUDE.md | 1 + SECURITY.md | 30 ++ docs/modules/ROOT/nav.adoc | 1 + docs/modules/ROOT/pages/security-model.adoc | 694 ++++++++++++++++++++++++++++ 5 files changed, 1084 insertions(+) diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 000000000..a3fd5983e --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,358 @@ +# Apache Camel Karaf - AI Agent Guidelines + +Guidelines for AI agents working on this codebase. + +## Project Info + +Apache Camel Karaf provides Apache Karaf (OSGi) runtime support for Apache +Camel: Karaf feature descriptors that install Camel and its components as OSGi +bundles, an OSGi-aware core (`camel-core-osgi`), a Blueprint XML DSL +(`camel-blueprint`), and Karaf shell commands for inspecting and controlling +running Camel contexts and routes. + +- Version: 4.18.2-SNAPSHOT +- Bundles Apache Camel: 4.18.1 +- Built against Apache Karaf: 4.4.8 (minimum Karaf 4.4.6) +- Java: 17+ +- Build: Maven + +It is a sub-project of Apache Camel, under the same PMC and the same security +process. + +## AI Agent Rules of Engagement + +These rules apply to ALL AI agents working on this codebase. + +### Attribution + +- All AI-generated content (GitHub PR descriptions, review comments, issue + comments) MUST clearly identify itself as AI-generated and mention the human + operator. Example: "_Claude Code on behalf of [Human Name]_" + +### PR Volume + +- An agent MUST NOT open more than 10 PRs per day per operator to ensure human + reviewers can keep up. +- Prioritize quality over quantity — fewer well-tested PRs are better than many + shallow ones. + +### Git branch + +- An agent MUST NEVER push commits to a branch it did not create. +- If a contributor's PR needs changes, the agent may suggest changes via review + comments, but must not push to their branch without explicit permission. +- An agent should prefer to use its own fork to push branches instead of the + main `apache/camel-karaf` repository. It avoids filling the main repository + with a long list of uncleaned branches. +- An agent must provide a useful name for the git branch. It should contain the + global topic and issue number if possible. +- After a Pull Request is merged or rejected, the branch should be deleted. +- `main` requires **linear history** and PRs are **squash-merged** (see + `.asf.yaml`). Keep branches rebased on `main`; do not add merge commits. + +### GitHub Issue Ownership + +camel-karaf tracks issues on **GitHub** (not JIRA): +<https://github.com/apache/camel-karaf/issues>. + +- An agent MUST ONLY pick up issues that are **unassigned**. +- If an issue is already assigned to a human, the agent must not reassign it or + work on it. +- Before starting work, the agent should comment on the issue stating it (and + its operator) is taking it, so work is not duplicated. +- Reference the issue from the PR so it is linked and auto-closed on merge. + +### PR Description Maintenance + +When pushing new commits to a PR, **always update the PR description** (and +title if needed) to reflect the current state of the changeset. Use +`gh pr edit --title "..." --body "..."` after each push. + +### PR Reviewers + +When creating a PR, **always identify and request reviews** from the most +relevant committers: + +- Run `git log --format='%an' --since='1 year' -- <affected-files> | sort | uniq -c | sort -rn | head -10` + to find who has been most active on the affected files. +- Use `git blame` on key modified files to identify who wrote the code being + changed. +- Cross-reference with the + [committer list](https://home.apache.org/committers-by-project.html#camel) + to ensure you request reviews from active committers. +- Request review from **at least 2 relevant committers** using + `gh pr edit --add-reviewer`. +- When all comments are addressed and checks are green, re-request review so + reviewers know the new changeset is ready. + +### Merge Requirements + +- An agent MUST NOT merge a PR if there are any **unresolved review + conversations**. +- An agent MUST NOT merge a PR without at least **one human approval**. +- An agent MUST NOT approve its own PRs — human review is always required. + +### Code Quality + +- Every PR must include tests for new functionality or bug fixes. +- Every PR must include documentation updates where applicable. +- The build (`mvn clean install`) is the gate; it must pass before pushing. + There is no separate enforced source-formatter plugin — match the style of + the surrounding code and the Apache Camel conventions. +- Any generated files (catalog, features) must be regenerated and committed if + the change affects them. + +### Asynchronous Testing: Use Awaitility Instead of Thread.sleep + +Do **NOT** use `Thread.sleep()` in test code. It leads to flaky, slow, and +non-deterministic tests. Use the +[Awaitility](https://github.com/awaitility/awaitility) library instead, which +is already available as a test dependency in this project. + +```java +import static org.awaitility.Awaitility.await; + +await().atMost(20, TimeUnit.SECONDS) + .untilAsserted(() -> assertEquals(1, context.getRoutes().size())); +``` + +**Rules:** + +- New test code MUST NOT introduce `Thread.sleep()` calls. +- When modifying existing test code that contains `Thread.sleep()`, migrate it + to Awaitility. +- Always set an explicit `atMost` timeout to avoid hanging builds. +- OSGi/Karaf integration tests (Pax Exam) are inherently asynchronous; use + Awaitility for service/route/context readiness rather than sleeping. + +### Issue Investigation (Before Implementation) + +Before implementing a fix, **thoroughly investigate** the issue's validity and +context. camel-karaf is a long-lived OSGi project — code often looks "wrong" +but exists for good OSGi reasons (classloader scoping, service dynamics, +Blueprint lifecycle). Do NOT jump straight to implementation. + +**Required investigation steps:** + +1. **Validate the issue**: Confirm the reported problem is real and + reproducible. Question assumptions in the issue description. +2. **Check git history**: Run `git log --oneline <file>` and `git blame + <file>`. Many fixes here are OSGi-dynamics workarounds (e.g. + `OsgiTypeConverter` delegate invalidation, Blueprint proxy bean method + resolution); understand *why* before changing. +3. **Search for related issues/PRs**: Look for prior discussion of the same + OSGi behavior; the same area is often touched repeatedly. +4. **Distinguish camel-karaf vs Camel core**: If the defect is really in a + packaged Camel component or in Camel core, the fix belongs in + `apache/camel`, and camel-karaf only re-releases the upgraded version. See + the Security Model below for the same split applied to vulnerabilities. +5. **Check if the "fix" reverts prior work**: If your change effectively + reverts a prior intentional OSGi commit, stop and reconsider; if still + justified, acknowledge it explicitly in the PR description. + +**Present your findings** to the operator before implementing. Flag risks, +ambiguities, or cases where the issue may be invalid. + +### Knowledge Cutoff Awareness + +AI agents have a training-data cutoff and may not know about recent releases or +API changes in Camel, Karaf, OSGi, Pax Exam or Blueprint. + +- When an issue, PR or code references a specific version of an external + dependency, **verify it exists** (web search, Maven Central, release notes) + before relying on or questioning it. +- Do not make authoritative claims about external project state based solely on + training knowledge; verify the current state. + +### Documentation Conventions + +When writing or modifying `.adoc` documentation under `docs/`: + +- **Use `xref:` for internal links**, not external `https://camel.apache.org/...` + URLs, for pages inside this Antora module. +- Keep the user guide (`docs/modules/ROOT/pages/index.adoc`) and the navigation + (`docs/modules/ROOT/nav.adoc`) in sync when adding pages. + +## Security Model + +camel-karaf has a documented threat model: +[`docs/modules/ROOT/pages/security-model.adoc`](docs/modules/ROOT/pages/security-model.adoc). +Use it when triaging security reports, deciding whether a finding warrants a +CVE, or reviewing a security-sensitive PR. For the **reporting** convention, +[`SECURITY.md`](SECURITY.md) at the repository root is the entry point. An +agent that discovers or is handed a suspected vulnerability MUST NOT open a +public issue, PR, or mailing-list post about it — follow the private Apache +Camel process and stop. + +### The one thing to internalize + +camel-karaf is a **runtime adapter, not a new data plane**. The data-plane +vulnerability classes (unsafe deserialization, XXE, expression/template +injection, path traversal, SSRF, Camel-header/bean-dispatch abuse, auth/authz +bypass, information disclosure, insecure defaults, back-end query injection) +live in **Apache Camel core and components**. Their canonical threat model is +the Apache Camel +[Security Model](https://github.com/apache/camel/blob/main/docs/user-manual/modules/ROOT/pages/security-model.adoc). +A defect in `camel-jackson` / `camel-xslt` / `camel-jms` (etc.) reached +through a Karaf feature is an **Apache Camel** report — route it there, do not +treat it as a camel-karaf finding. camel-karaf's own model covers only the +**Karaf-specific delta**. + +### Trust assumptions (inherited from Apache Camel) + +- **camel-karaf committers** are trusted to ship secure defaults and to not + weaken a boundary Camel core holds. +- **Bundle and route authors** (including authors of **Blueprint XML**) are + **fully trusted**. Blueprint XML is route-author code exactly as Java/XML/YAML + DSL is in core; code execution by an author is by design, not a vulnerability. +- **Karaf operators/deployers** are **fully trusted**. Installing a + feature/bundle, running the deployer, or using the Karaf shell are + privileged code-deployment actions. Operator misconfiguration is not a + camel-karaf vulnerability unless a camel-karaf default exposed it. +- **External message senders** are **untrusted** — the primary attacker model, + but the code that must withstand them is overwhelmingly Camel core, not + camel-karaf. + +### Karaf-specific in scope + +A report is in scope for **camel-karaf specifically** only when the defect is +in code this repo ships and is one of: + +- The OSGi resolution layer (`camel-core-osgi`) **widening, for untrusted + message data, a class/bean/component/language/dataformat sink that + flat-classpath Camel core had closed**. +- A camel-karaf-authored class (`camel-core-osgi`, `camel-blueprint`, shell) + being itself a primary deser/XXE/path-traversal/header-injection sink (not a + passthrough to a Camel component). +- The Karaf shell or Blueprint integration **adding a capability beyond** what + the DSL / JMX management surface already grants. + +### Karaf-specific out of scope + +- A data-plane defect in a **packaged Camel component** → it's an Apache Camel + report; redirect, do not dismiss. +- Installing a hostile/vulnerable feature or bundle, or `wrap:`-ing an + untrusted JAR — trusted operator action. +- **OSGi is not a security sandbox**; no isolation is promised between + co-deployed bundles; camel-karaf does not rely on the (deprecated) OSGi + `SecurityManager`. +- Pax-URL / Maven artifact-resolution integrity (repo TLS, checksum/PGP) — + Karaf/Pax-URL/operator configuration. +- Exposing the Karaf shell/SSH on an untrusted network — it is a management + surface, like camel-management/JMX in core. +- Build-time `tooling/` (feature/catalog/upgrade Maven plugins) and + shipped-but-unsupported `tests/`, `tests/examples/`, `archetypes/`. +- Everything the Apache Camel Security Model places out of scope, applied to + packaged components. + +### Operator hardening (surface when reviewing a deployment) + +- Keep the Karaf shell / SSH on loopback or a management network behind a + strong JAAS realm. +- Restrict who may install features/bundles and run the deployer. +- Harden Pax-URL: HTTPS Maven repositories, checksum/PGP verification, avoid + `wrap:`-ing untrusted JARs. +- Keep the bundled Camel patched (track camel-karaf releases following Camel + security releases). +- Apply the full Apache Camel operator hardening checklist (security profile + `prod`, vault secrets, JSSE TLS, strip `Camel*` headers at untrusted + boundaries, no Java serialization on untrusted consumers). + +### Committer review checklist (security-sensitive PRs) + +When a PR touches `camel-core-osgi`, `camel-blueprint`, the shell, or the +feature descriptors: + +- Does an `Osgi*Resolver` / `OsgiClassResolver` / `OsgiBeanRepository` change + let a *name derived from message data* select a class/bean/component that + flat-classpath Camel would not? That re-opens a Camel-core sink and **is** in + scope. +- Does a Blueprint change cause **message data** (not bundle-author XML) to + drive bean instantiation? +- Does a new/changed shell command add a capability beyond list / start / stop + / suspend / resume / stats — i.e., make the shell more powerful than the + JMX/DSL surface it mirrors? +- Does a feature descriptor change introduce a security-relevant default + (auto-installed bundle, transport)? Defaults err toward least surprise. +- If the change is really fixing a Camel-core data-plane issue, it belongs in + `apache/camel`; here, only the version upgrade. + +## Structure + +``` +camel-karaf/ +├── core/ # OSGi-aware Camel core (camel-core-osgi + repackaged core modules) +├── components/ # ~330 Camel components packaged for OSGi/Karaf (incl. camel-blueprint) +├── features/ # Karaf feature descriptors (camel-features.xml, spring-features.xml) +├── shell/ # Karaf shell commands (camel:context-*, camel:route-*, ...) +├── platforms/ # Karaf platform glue and command-core +├── catalog/ # Karaf-specific Camel catalog +├── tooling/ # Build-time Maven plugins + camel-upgrade tool (out of security model) +├── archetypes/ # camel-archetype-blueprint (sample scaffolding) +├── tests/ # Pax Exam OSGi integration tests, examples +└── docs/ # Antora AsciiDoc docs (incl. security-model.adoc) +``` + +## Build + +```bash +mvn clean install # full build +mvn clean install -DskipTests # skip tests +mvn clean install -pl shell -am # single module with dependencies +``` + +OSGi integration tests use Pax Exam and are resource intensive; do not +parallelize Maven jobs. + +### Upgrading the bundled Camel version + +The `tooling/camel-upgrade` tool regenerates wrappers/features for a new Camel +release. Clone `apache/camel` next to this repo, check out the target +`camel-x.y.z` tag, build camel-karaf, then run the upgrade tool (see +`README.md`). Review the diff before opening a PR. The upgrade PR is the +mechanism by which Apache Camel security fixes reach camel-karaf. + +## Conventions + +OSGi-aware core classes: +- `Osgi<Name>` prefix in `org.apache.camel.karaf.core` (e.g. `OsgiClassResolver`, + `OsgiComponentResolver`, `OsgiBeanRepository`). + +Blueprint: +- `Camel<Name>FactoryBean` in `org.apache.camel.blueprint`; the namespace + handler is `CamelNamespaceHandler`. + +Shell commands: +- One class per command in `org.apache.camel.karaf.shell`, extending + `CamelCommandSupport`, annotated `@Command(scope = "camel", name = "...")` + and `@Service`. + +Features: +- Declared in `features/src/main/feature/camel-features.xml`; one `<feature>` + per Camel component, bundles referenced by `mvn:` (or `wrap:mvn:` for + non-OSGi JARs). + +Tests: +- `*Test.java` (JUnit 5); OSGi integration tests use Pax Exam under `tests/`. + +## Commits + +camel-karaf uses conventional-style subjects with the GitHub issue number: + +``` +fix(#NNN): Brief description +feat(#NNN): Brief description +ci: Brief description +``` + +PRs are squash-merged, so the squash subject gets a `(#PR)` suffix +automatically. Reference the GitHub issue so it auto-closes on merge. + +## Links + +- https://camel.apache.org/ +- https://github.com/apache/camel-karaf +- https://github.com/apache/camel-karaf/issues +- https://camel.apache.org/security/ +- [email protected] +- https://camel.zulipchat.com/ diff --git a/CLAUDE.md b/CLAUDE.md new file mode 120000 index 000000000..47dc3e3d8 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1 @@ +AGENTS.md \ No newline at end of file diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 000000000..2650fd954 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,30 @@ +# Security Policy + +## Supported Versions + +To see which versions of Apache Camel Karaf are supported please refer to this [page](https://camel.apache.org/download/). + +## Reporting a Vulnerability + +For information on how to report a new security problem please see [here](https://camel.apache.org/security/). + +Apache Camel Karaf is a sub-project of Apache Camel and uses the same Apache +Camel / ASF private vulnerability reporting process. Do not open a public +issue, pull request, or mailing-list post about an unpublished vulnerability. + +## Security Model + +Before submitting a report, please read the project's +[Security Model](docs/modules/ROOT/pages/security-model.adoc). It documents who is +trusted, where the trust boundaries sit, and which classes the Camel PMC accepts as +a camel-karaf vulnerability versus what is operator responsibility (installing +features/bundles, exposing the Karaf shell, Pax-URL artifact integrity) or +out of scope. + +camel-karaf is a runtime adapter: data-plane vulnerability classes +(deserialization, XXE, header injection, path traversal, SSRF, etc.) live in +Apache Camel core and components. The canonical model for those is the Apache +Camel [Security Model](https://github.com/apache/camel/blob/main/docs/user-manual/modules/ROOT/pages/security-model.adoc). +A defect in a packaged Camel component reached through a Karaf feature is an +Apache Camel report, not a camel-karaf one. Reports outside the documented +scope will be closed with a reference to the Security Model page. diff --git a/docs/modules/ROOT/nav.adoc b/docs/modules/ROOT/nav.adoc index 633afba97..f3320c5fb 100644 --- a/docs/modules/ROOT/nav.adoc +++ b/docs/modules/ROOT/nav.adoc @@ -1,2 +1,3 @@ * xref:index.adoc[User Guide] ** xref:components.adoc[Supported Components] +** xref:security-model.adoc[Security Model] diff --git a/docs/modules/ROOT/pages/security-model.adoc b/docs/modules/ROOT/pages/security-model.adoc new file mode 100644 index 000000000..06ec4d5c5 --- /dev/null +++ b/docs/modules/ROOT/pages/security-model.adoc @@ -0,0 +1,694 @@ += Security Model + +This page documents the Apache Camel Karaf security model: who is trusted, +where the trust boundaries sit, what counts as a camel-karaf vulnerability, +and what is left to the Karaf operator and the bundle/route author. It is the +reference used when triaging security reports against camel-karaf and when +deciding whether a behaviour should be hardened here or addressed by the +deployment. + +[IMPORTANT] +==== +camel-karaf is a *runtime adapter*, not a new data plane. It packages Apache +Camel and ~330 Camel components as OSGi bundles and Karaf features, adds an +OSGi-aware resolution layer (`camel-core-osgi`), a Blueprint DSL +(`camel-blueprint`), and a set of Karaf shell commands. The data-plane +vulnerability classes (unsafe deserialization, XXE, expression/template +injection, path traversal, SSRF, Camel-header/bean-dispatch abuse, auth/authz +bypass, information disclosure, insecure defaults, back-end query injection) +live in Apache Camel core and components, **not** in this repository. + +*The canonical threat model for those classes is the Apache Camel* +https://github.com/apache/camel/blob/main/docs/user-manual/modules/ROOT/pages/security-model.adoc[*Security Model*]. +This document covers only the *Karaf-specific delta* and defers everything +else to that page. A finding in `camel-jackson`, `camel-xslt`, `camel-jms` +(etc.) reached through a Karaf feature is an *Apache Camel* finding, triaged +against Camel's model — repackaging it for OSGi does not make it a new class +and does not move ownership to camel-karaf. +==== + +== Document status + +* *Project*: Apache Camel Karaf (`org.apache.camel.karaf:camel-karaf`). +* *Version binding*: written against `4.18.2-SNAPSHOT` (last release + `camel-karaf-4.18.1`), bundling Apache Camel `4.18.1`, built against Apache + Karaf `4.4.8`, minimum Apache Karaf `4.4.6`, Java 17. A report against + camel-karaf version _N_ is triaged against this model as it stood at _N_, + not at HEAD. +* *Status*: *accepted — all waves (Q1–Q17) ratified by a Camel PMC maintainer + on 2026-05-15*. Every non-trivial claim carries a dated provenance tag + (below); the <<open-questions>> section is retained as the ratification + record. Revise only per <<changes>>. +* *Provenance legend*: +** _(documented)_ — stated in camel-karaf's own docs/code, or lifted with + citation from the Apache Camel Security Model / `SECURITY.md`, which + governs this sub-project (same PMC, same private security list, same + advisory index). +** _(maintainer)_ — confirmed by a camel-karaf / Camel PMC maintainer in + response to this process. All waves (Q1–Q17) confirmed 2026-05-15. +** _(inferred)_ — reasoned from code structure, the parent model, or OSGi/Karaf + domain knowledge; not yet ratified. None remain in this revision; the tag + stays defined so a future revision's new claim starts _(inferred)_ with a + matching <<open-questions>> entry until ratified. +* *Reporting cross-reference*: camel-karaf uses the Apache Camel vulnerability + reporting process. Findings that fall under <<security-properties>> are + reported per `SECURITY.md` / link:https://camel.apache.org/security/[Apache + Camel Security]; findings that fall under <<out-of-scope>> or + <<not-provided>> will be closed citing this document. +* *Provenance retention*: the dated provenance tags are *retained* in this + accepted version, not stripped — they are the chain of authority cited when + a report is closed (e.g. "not a bug — see <<not-provided>>, maintainer-tagged + with the ratification date"). Tag-free maintenance in the parent Apache Camel Security + Model's style is a later option, at PMC discretion, only once the model has + been exercised in real triage. + +camel-karaf is the Apache Karaf (OSGi) runtime support for Apache Camel. It +lets a Camel application run inside a Karaf/OSGi container: it ships Karaf +feature descriptors that install Camel and its components as bundles, an +OSGi-aware core (`camel-core-osgi`) that resolves Camel components, languages, +data formats, type converters and beans through the OSGi service registry and +bundle class loaders, a Blueprint XML DSL for declaring Camel contexts and +routes, and Karaf shell commands for inspecting and controlling running Camel +contexts and routes. + +== Audience + +* *Security researchers and CVE reporters* who need to know what the Camel PMC + will accept as a camel-karaf vulnerability — and which reports belong against + Apache Camel core instead. _(documented)_ +* *Automated triage tooling and AI-assisted review* that needs an + authoritative scope statement for the Karaf delta. _(documented)_ +* *camel-karaf committers* reviewing pull requests to `camel-core-osgi`, + `camel-blueprint`, the shell, the feature descriptors or the build tooling. + _(documented)_ +* *Karaf operators and deployment owners* who need to know which hardening + responsibilities the OSGi/Karaf layer delegates to them. _(documented)_ + +== Trust model + +camel-karaf inherits the Apache Camel trust model verbatim and refines the +operator and author roles for an OSGi/Karaf deployment. The fundamental Camel +trust boundary still holds: *the route plus everything the operator +configured* is trusted; *the data flowing through the route* is untrusted. +_(documented — Apache Camel Security Model, "Trust model")_ + +=== Roles + +[cols="1,1,3",options="header"] +|=== +| Role | Trust level | What this role can do + +| camel-karaf committers and component packagers +| Trusted +| Author `camel-core-osgi`, the Blueprint integration, the shell commands and + the feature descriptors; choose OSGi metadata and feature wiring; publish + releases. The project relies on these contributors to ship secure defaults + and to not weaken a boundary Camel core holds. _(documented)_ + +| Bundle and route authors (people writing Camel routes — Java, XML, YAML or + *Blueprint* DSL — and packaging them as OSGi bundles) +| Fully trusted +| Execute arbitrary Java in `.bean()` / `.process()`, evaluate arbitrary + expressions, reference any class wired into their bundle, declare any + component, and define beans in Blueprint XML. Blueprint XML is route-author + code in exactly the sense Java/XML/YAML DSL is in Camel core; code execution + by a bundle/route author is by design and is not a camel-karaf + vulnerability. _(maintainer, 2026-05-15)_ + +| Karaf operators / deployers (people who run the Karaf container) +| Fully trusted +| Install feature repositories and features, install/start/stop/refresh + bundles, run the Karaf shell (locally or over SSH), configure JAAS realms + and shell/SSH access, configure Pax-URL (`mvn:` repositories, `wrap:`), + configure the OSGi framework and the JVM. Installing a feature or a bundle + *is* arbitrary code execution; operator misconfiguration is not a + camel-karaf vulnerability unless a camel-karaf default exposed it. + _(maintainer, 2026-05-15)_ + +| External message senders (HTTP clients, JMS producers, file droppers, etc.) +| Untrusted +| Send messages into a Camel route running inside Karaf. This is the primary + attacker model — but the framework code that must hold the boundary for + these senders is overwhelmingly in Apache Camel core/components, not in + camel-karaf. _(documented — Apache Camel Security Model)_ +|=== + +=== Trust boundaries + +The data-plane trust boundary is Camel's and is documented in the parent +model: untrusted message data must not become code, must not redirect the +route, must not be deserialised into arbitrary types, must not be parsed in +ways that resolve remote resources. _(documented — Apache Camel Security +Model, "Trust boundaries")_ + +camel-karaf adds three boundaries of its own, all *administrative*, not +data-plane: + +* *The OSGi modularity boundary is not a security sandbox.* Separate bundle + class loaders, package wiring and the service registry exist for modular + deployment and version management, not to contain a hostile bundle. A bundle + installed into the framework is trusted code, exactly as a route author is + trusted in Camel core. camel-karaf does not rely on the OSGi + `SecurityManager` / conditional-permission model (deprecated and effectively + removed on modern JDKs). _(maintainer, 2026-05-15)_ +* *The Karaf shell is a management surface.* Its trust boundary is the console + itself (local terminal, or SSH gated by Karaf's JAAS realm), not the + individual `camel:*` command. _(maintainer, 2026-05-15)_ +* *Feature/bundle installation is an operator action.* The boundary is "who + may add a feature repository or install a bundle", which is Karaf/JAAS + configuration, not a camel-karaf API. _(maintainer, 2026-05-15)_ + +=== Component families + +[cols="2,2,1,1",options="header"] +|=== +| Family | Representative entry point | Touches host? | In this model? + +| OSGi resolution core (`camel-core-osgi`) +| `OsgiComponentResolver`, `OsgiLanguageResolver`, `OsgiDataFormatResolver`, + `OsgiClassResolver`, `OsgiBeanRepository`, `OsgiTypeConverter`, + `OsgiPackageScanClassResolver`, `OsgiEventAdminNotifier`, + `OsgiCamelContextPublisher` +| Yes — OSGi service registry, bundle class loaders, EventAdmin +| *Yes* — Karaf-specific glue; in scope only as a *boundary-preservation* + obligation (see <<security-properties>>) + +| Blueprint DSL (`camel-blueprint`, `camel-blueprint-main`) +| `CamelNamespaceHandler`, the `Camel*FactoryBean` classes, JSSE + `KeyStoreParametersFactoryBean` / `KeyManagersParametersFactoryBean` +| Yes — parses Blueprint XML supplied by the bundle author +| *Yes, as trusted route-author input* — equivalent to Spring/Java/YAML DSL in + Camel core + +| Karaf shell commands (`shell/`, `platforms/commands`) +| `camel:context-list/-start/-stop/-suspend/-resume`, `camel:route-*`, + `camel:endpoint-list/-stats`, `camel:rest-*` +| Yes — enumerates `CamelContext` OSGi services; mutates context/route + lifecycle +| *Yes, as a management surface* — analogous to camel-management / JMX in core + +| Feature descriptors (`features/`, `platforms/karaf`) +| `camel-features.xml`, `spring-features.xml` (`mvn:` / `wrap:` Pax-URL refs) +| Yes — declares artifacts Karaf resolves and installs +| *Yes, as an operator-driven install manifest* — see <<out-of-scope>> + +| Build-time Maven tooling (`tooling/`) +| `camel-karaf-maven-plugin`, `camel-karaf-feature-maven-plugin`, + `camel-catalog-generator-karaf-maven-plugin`, `camel-upgrade` +| Build host only +| *No* — out of scope per <<out-of-scope>> (build-time, not a runtime + boundary) + +| Samples / scaffolding (`tests/examples`, `archetypes/`) +| `camel-archetype-blueprint`, `tests/examples/*` +| n/a +| *No* — shipped but unsupported, see <<out-of-scope>> +|=== + +== Scope: what camel-karaf adds to the attack surface + +A report is in scope for *camel-karaf* (rather than for Apache Camel core) +only when the defect is in code this repository ships and the defect is one of +the Karaf-specific classes below. Everything in Camel's in-scope list remains +in scope *for Apache Camel* when reached through a Karaf feature, and is +triaged against the parent model. + +[[security-properties]] +=== Security properties camel-karaf provides + +[cols="3,3,1",options="header"] +|=== +| Property (default / reasonably-expected configuration) +| What a violation looks like +| Indicative severity + +| The OSGi resolution layer preserves Camel's data-plane boundary: it never + lets *untrusted message data* select an arbitrary class, component, + language, data format or bean that the route author did not wire in. + `OsgiClassResolver` / `OsgiBeanRepository` / `Osgi*Resolver` resolve only + names that Camel core would resolve, scoped to the route's bundle wiring. + _(maintainer, 2026-05-15)_ +| A crafted header or body causes `camel-core-osgi` to load or instantiate an + attacker-named class/bean/component that flat-classpath Camel would not — + i.e., OSGi resolution *widens* a sink Camel core had closed +| Critical (CVSS 9.0-9.8) — same tier as the Camel deserialisation / + bean-dispatch class it would re-open + +| The Blueprint DSL exposes no capability beyond what Camel's other DSLs + expose; Blueprint XML is processed as trusted route-author input only. + _(maintainer, 2026-05-15)_ +| Blueprint parsing turns *message data* (not bundle-author XML) into bean + instantiation or code execution +| Critical (CVSS 9.0-9.8) if reachable from message data; otherwise + by-design (route-author trust) + +| Karaf shell commands act only on Camel contexts/routes visible in the OSGi + service registry and expose only lifecycle/inspection operations + (list, start, stop, suspend, resume, stats). They add no capability a route + author or operator does not already have. _(maintainer, 2026-05-15)_ +| A `camel:*` command executes code, reaches an endpoint, or affects a context + the caller could not already affect through the DSL or JMX — i.e., the shell + is *more* powerful than the management surface it mirrors +| Severity of the underlying capability; the shell is in scope only if it + *adds* one + +| camel-karaf's own classes do not introduce new unsafe deserialisation, XXE, + path-traversal or header-injection sinks beyond those in the Camel + components it packages. _(maintainer, 2026-05-15)_ +| A `camel-core-osgi` / `camel-blueprint` / shell code path is itself the sink + (not merely a passthrough to a Camel-core component) +| Severity of the underlying class (per the Apache Camel Security Model) +|=== + +Severity tiers are indicative and follow the parent model; the PMC assigns the +definitive CVSS vector per report. _(documented — Apache Camel Security +Model)_ + +[[not-provided]] +=== Security properties camel-karaf does *not* provide + +* *OSGi/Karaf is not a security sandbox.* A bundle installed into the + framework runs with full JVM privileges. Bundle isolation is modularity, not + containment; do not treat "it's a separate bundle" as a trust boundary. + _(maintainer, 2026-05-15)_ +* *No isolation between co-deployed bundles.* Camel contexts from different + bundles share a JVM, the OSGi service registry and (subject to package + wiring) classes. camel-karaf does not promise tenant isolation between + bundles in one Karaf instance. _(maintainer, 2026-05-15)_ +* *No artifact authentication for features.* camel-karaf publishes feature + descriptors that reference artifacts by `mvn:` / `wrap:` Pax-URL. Transport + security, checksum and signature verification of those artifacts are + Pax-URL / Karaf / operator configuration, not something camel-karaf + enforces. _(maintainer, 2026-05-15)_ +* *No authentication or authorization on the shell itself.* The `camel:*` + commands inherit whatever the Karaf console / SSH / JAAS layer enforces; + camel-karaf does not add its own access control. _(maintainer, 2026-05-15)_ +* *False friend — `wrap:`* makes a non-OSGi JAR loadable; it does not vet, + sandbox or sign it. _(maintainer, 2026-05-15)_ +* *False friend — the Karaf shell looks like a read-only admin view* but + `context-start/-stop/-suspend/-resume` and `route-start/-stop/-suspend/-resume` + mutate running integrations. _(maintainer, 2026-05-15)_ +* All data-plane "properties not provided" from the Apache Camel Security + Model (no compression-bomb defence, no input authentication, no + constant-time guarantees, DoS via unthrottled routes is operator + responsibility, etc.) apply unchanged. _(documented — Apache Camel Security + Model, "Out of scope" / "Known limitations")_ + +[[out-of-scope]] +== Out of scope + +The following are *not* camel-karaf vulnerabilities. Reports in these +categories are closed with a reference to this document (data-plane reports +are redirected to the Apache Camel process, not dismissed). + +* *Everything the Apache Camel Security Model places out of scope*, applied to + components packaged here: route-author code execution, route-author building + unparameterised back-end queries, documented opt-ins + (`allowJavaSerializedObject=true`, `transferException=true`, + `trustAllCertificates=true`, `mapJmsMessage=true`, …), DoS via unthrottled + routes, exposing management surfaces on a public network, third-party + transitive CVEs not reachable through Camel code, scanner reports without a + trust-boundary PoC. _(documented — Apache Camel Security Model)_ +* *Data-plane vulnerabilities in a packaged Camel component.* A + deserialisation / XXE / header-injection / path-traversal defect in + `camel-jackson`, `camel-xslt`, `camel-jms`, `camel-file`, … reached through + a Karaf feature is an *Apache Camel* vulnerability. It is reported and fixed + in `apache/camel` and triaged against the parent model; camel-karaf only + re-releases the upgraded component. _(documented)_ +* *Installing a hostile or vulnerable feature/bundle.* Adding a feature + repository, installing a bundle, or `wrap:`-ing an arbitrary JAR is a + trusted operator action equivalent to deploying code. That the operator can + install something dangerous is not a camel-karaf vulnerability. + _(maintainer, 2026-05-15)_ +* *Pax-URL / Maven artifact-resolution integrity* (plaintext repositories, + missing checksum/signature enforcement, dependency confusion in the + operator's Maven settings). This is Karaf/Pax-URL/operator configuration. + _(maintainer, 2026-05-15)_ +* *Build-time Maven tooling* (`tooling/`): the feature, catalog-generator and + Karaf Maven plugins and the `camel-upgrade` tool run on a developer/CI host + at build time, on inputs the developer controls. Build/release/SDLC hygiene + is not part of this model. _(documented — threat-model skill §1)_ +* *Shipped-but-unsupported code*: `tests/`, `tests/examples/`, + `archetypes/camel-archetype-blueprint`. These are samples and scaffolding, + separately authored, not covered by camel-karaf's runtime guarantees; + threat-model them separately if ever promoted. _(maintainer, 2026-05-15)_ +* *The Karaf container, Blueprint extender, Pax-Web, Pax-URL, ConfigAdmin, + EventAdmin or the OSGi framework themselves.* camel-karaf integrates with + these; defects in them are reported to Apache Karaf / the relevant project. + A report must show camel-karaf code, not the container, is the cause. + _(maintainer, 2026-05-15)_ +* *Stale documentation versioning* (e.g. `docs/antora.yml` display version) + and other non-security metadata drift. _(documented — threat-model skill + §1)_ + +=== Deprecated and removed components + +camel-karaf tracks the Apache Camel component lifecycle. A component carrying +the `(deprecated)` suffix is on a removal path with a documented replacement; +a report against it is triaged on the private list but the primary remediation +is the documented migration. A component no longer shipped in any supported +camel-karaf release is out of scope — the resolution is to upgrade. This +mirrors the parent model's lifecycle rule. _(documented — Apache Camel +Security Model, "Deprecated and removed components")_ + +=== Known limitations + +* *camel-karaf lags Camel core by a patch cadence.* A data-plane CVE fixed in + Apache Camel is addressed in camel-karaf by upgrading the bundled Camel + version (see the upgrade tooling), not by a separate fix here. The window + between a Camel release and the matching camel-karaf release is expected, + not a camel-karaf vulnerability. _(maintainer, 2026-05-15)_ +* *Heritage permissive defaults are Camel's, not Karaf's.* Where a packaged + component defaults permissively (FTP, plain SMTP, `mapJmsMessage=true`, + etc.), that default and any decision to tighten it belong to Apache Camel. + _(documented — Apache Camel Security Model, "Known limitations")_ +* *The Camel security-policy enforcement framework (`camel.main.profile`, + `secret` / `insecure:ssl` / `insecure:serialization` / `insecure:dev`) + applies as in core* when the corresponding Camel main is used; camel-karaf + does not disable or replace it. Its behaviour under Blueprint/OSGi + bootstrapping is a confirmation target. _(maintainer, 2026-05-15)_ + +== Environment, host effects and configuration variants + +* *Host effects of `camel-core-osgi`.* When active it registers OSGi service + listeners, publishes each `CamelContext` as an OSGi service + (`OsgiCamelContextPublisher`), and — if the OSGi EventAdmin service is + present — emits Camel lifecycle events to EventAdmin + (`OsgiEventAdminNotifier`). It reads bundle class loaders and the service + registry. It does not, by design, open network sockets, spawn processes, or + install signal handlers of its own. _(maintainer, 2026-05-15)_ +* *Concurrency.* `camel-core-osgi` participates in OSGi service dynamics + (services come and go); thread-safety expectations are Camel core's plus + OSGi's. _(maintainer, 2026-05-15)_ +* *Configuration variants that change the envelope.* Whether the Karaf shell / + SSH is enabled and how its JAAS realm is configured; whether Pax-URL + enforces repository TLS and PGP; whether the deprecated OSGi + `SecurityManager` is engaged (camel-karaf does not assume it is); the bundled + Camel version and its security profile. Each is *operator* configuration; + none is a camel-karaf build flag. There are no camel-karaf compile-time + defines that toggle a security property. _(maintainer, 2026-05-15)_ + +== Input-trust matrix (Karaf-specific surfaces) + +[cols="2,2,1,2",options="header"] +|=== +| Surface | Input | Attacker-controllable? | Who must enforce safety + +| Karaf shell `camel:*` +| Command arguments (context/route names) +| No — supplied by an authenticated console operator +| Karaf JAAS/SSH access control; operator keeps the console off public + networks + +| `camel-blueprint` +| Blueprint XML (`OSGI-INF/blueprint/*.xml`) in a bundle +| No — authored by the trusted bundle author +| Bundle author (it is route code); same status as Spring/Java/YAML DSL + +| `camel-core-osgi` +| Component/language/dataformat/class/bean *names* to resolve +| Only if a route passes message data into a resolver — which is a + *Camel-core* boundary question +| Camel core must not pass untrusted data to a resolver; `camel-core-osgi` + must not widen what Camel core would resolve + +| Feature descriptors +| `mvn:` / `wrap:` artifact coordinates +| No — the descriptor is authored here; resolution is operator-configured +| Operator (Pax-URL repos, TLS, checksum/PGP); Karaf + +| Packaged Camel component +| Exchange body / headers / attachments from a Camel consumer +| *Yes* +| Apache Camel core/component code, per the parent Security Model — *not* + camel-karaf +|=== + +== Adversary model + +* *Primary adversary*: an external message sender feeding a route running in + Karaf. The code that must withstand them is in Apache Camel core/components; + camel-karaf's obligation is to *not weaken* that boundary through the OSGi + resolution layer. _(documented / maintainer, 2026-05-15)_ +* *In scope for camel-karaf specifically*: an attacker who can get *untrusted + message data* to influence OSGi resolution (class/bean/component selection) + in a way flat-classpath Camel would not allow. _(maintainer, 2026-05-15)_ +* *Explicitly out of scope*: anyone who can install a bundle/feature, run the + Karaf shell, or edit Blueprint XML or Pax-URL configuration — these are + trusted operator/author capabilities; such an actor "has already won". + _(maintainer, 2026-05-15)_ +* *Out of scope*: a co-deployed bundle attacking another bundle in the same + Karaf instance — OSGi is not an isolation boundary (see <<not-provided>>). + _(maintainer, 2026-05-15)_ + +== Operator and author responsibilities + +None of these are camel-karaf vulnerabilities if skipped; all materially +reduce attack surface. They are in addition to the Apache Camel deployment +hardening checklist, which applies unchanged. + +* *Treat the Karaf shell / SSH as a management surface.* Bind it to loopback + or a management network, require a strong JAAS realm, and do not expose it + to untrusted networks — exactly as for camel-management / JMX / Jolokia in + Camel core. _(maintainer, 2026-05-15)_ +* *Control who may install features and bundles.* Restrict the Karaf + `feature`/`bundle` admin commands and the deployer to trusted operators; + installing code is a privileged action. _(maintainer, 2026-05-15)_ +* *Harden Pax-URL artifact resolution.* Use HTTPS Maven repositories and + enable checksum/PGP verification; avoid `wrap:`-ing untrusted JARs. + _(maintainer, 2026-05-15)_ +* *Keep the bundled Camel patched.* Track camel-karaf releases that follow + Apache Camel security releases; subscribe to the Camel announce list. + _(documented — Apache Camel Security Model, "Deployment hardening")_ +* *Apply the full Apache Camel operator hardening checklist* (security profile + `prod`, vault-backed secrets, JSSE TLS, strip `Camel*` headers at untrusted + boundaries, no Java serialisation on untrusted consumers, least privilege, + minimal dependency set). _(documented — Apache Camel Security Model, + "Deployment hardening")_ +* *Bundle authors: treat Blueprint XML as code.* Do not generate Blueprint or + route definitions from untrusted input, and filter `Camel*` headers from + untrusted producers inside the route, as in core. _(maintainer, 2026-05-15)_ + +== Known misuse patterns + +* *Treating an OSGi bundle boundary as a security boundary.* Co-deploying a + less-trusted bundle next to a sensitive one and assuming OSGi isolates them. + It does not — both run in one JVM. Isolate at the process/container level + instead. _(maintainer, 2026-05-15)_ +* *Exposing the Karaf SSH console on a public interface.* The `camel:*` + commands then let any console-authenticated party stop or suspend + production routes. Keep the console on a trusted network. _(maintainer, 2026-05-15)_ +* *`wrap:`-ing an untrusted or unmaintained JAR* and assuming OSGi vets it. + `wrap:` only adds OSGi metadata; the code runs with full privileges. + _(maintainer, 2026-05-15)_ +* *Pointing Pax-URL at plaintext or unauthenticated Maven repositories* and + installing features from them. _(maintainer, 2026-05-15)_ +* *Generating Blueprint XML or route DSL from request data.* That is + route-author code built from untrusted input — the route is at fault, as in + Camel core. _(maintainer, 2026-05-15)_ + +[[known-non-findings]] +== Known non-findings (recurring false positives) + +This section is the highest-leverage input for automated/AI triage; it can be +fed back as a suppression list. + +* *"`camel-core-osgi` calls `Bundle.loadClass` / reflective class loading"* — + by design: it resolves the *same names Camel core resolves*, scoped to the + route bundle. In scope only if message data selects the name (see Q5); the + reflective call itself is not the finding. _(maintainer, 2026-05-15)_ +* *"Blueprint XML is parsed / beans are instantiated from XML"* — Blueprint is + trusted route-author input, equivalent to Spring/Java/YAML DSL. Not a + finding unless the XML is built from message data. _(maintainer, 2026-05-15)_ +* *"Karaf shell command starts/stops a Camel context"* — intended management + capability behind the authenticated console; equivalent to a JMX/DSL + operation. _(maintainer, 2026-05-15)_ +* *"Feature XML references `wrap:` / plaintext-looking `mvn:` URLs"* — feature + descriptors are install manifests; transport/integrity is operator/Pax-URL + configuration, out of scope here. _(maintainer, 2026-05-15)_ +* *"A packaged Camel component has a known CVE class"* — that is an Apache + Camel finding; route it to the Camel process, not camel-karaf, unless the + defect is in camel-karaf code. _(documented)_ +* *"Unchecked input / missing validation in `tooling/` or `tests/`"* — build + tooling and samples are out of scope. _(documented)_ + +[[triage-dispositions]] +== Triage dispositions + +A report, scanner hit or AI analysis judged against this model receives +exactly one of these. A finding that fits none is `MODEL-GAP` and triggers a +model revision (see <<changes>>) rather than an ad-hoc call. + +[cols="2,3,2",options="header"] +|=== +| Disposition | Meaning | Licensed by + +| `VALID` +| Violates a camel-karaf property via an in-scope adversary/input +| <<security-properties>>, input-trust matrix, adversary model + +| `REDIRECT: camel-core` +| Real vulnerability, but in a packaged Camel component / Camel core, not + camel-karaf code — route to the Apache Camel process +| <<out-of-scope>>, parent Security Model + +| `VALID-HARDENING` +| No property violated, but a camel-karaf API makes a known misuse easy + enough to harden at maintainer discretion (typically no CVE) +| "Known misuse patterns" + +| `OUT-OF-MODEL: trusted-actor` +| Requires installing a bundle/feature, shell access, or editing + Blueprint/Pax-URL config — all trusted operator/author capabilities +| Trust model, adversary model + +| `OUT-OF-MODEL: unsupported-component` +| Lands in `tooling/`, `tests/`, `tests/examples/` or `archetypes/` +| <<out-of-scope>> + +| `BY-DESIGN: property-disclaimed` +| Concerns a property camel-karaf explicitly does not provide (OSGi + sandboxing, bundle isolation, feature artifact authentication) +| <<not-provided>> + +| `KNOWN-NON-FINDING` +| Matches a documented recurring false positive +| <<known-non-findings>> + +| `MODEL-GAP` +| Cannot be cleanly routed to any of the above +| triggers <<changes>> +|=== + +[[changes]] +== Conditions that would change this model + +Revise when: camel-karaf gains a new public surface (e.g. a new shell command +family, a REST/HTTP admin endpoint, a non-Blueprint config DSL); the OSGi +resolution layer starts consuming message data; a build-time tool is promoted +into a runtime component; the minimum Karaf/OSGi version or the Java baseline +changes in a way that affects the (non-)reliance on the OSGi +`SecurityManager`; the relationship to the Apache Camel security process +changes; or **a report cannot be cleanly routed to one +<<triage-dispositions>> disposition** — a `MODEL-GAP` means this model is +incomplete and must be revised, not worked around. _(documented — threat-model +skill §4.12)_ + +[[open-questions]] +== Ratification record + +This section is the dated chain of authority for the model. Every wave of +proposed answers and the maintainer's ratification is kept here verbatim (not +silently dropped), because this page is cited when closing reports. The model +is *fully ratified as of 2026-05-15*; no questions are open. A future +<<changes>> trigger adds a new dated wave here rather than rewriting a past +record. + +*Wave 1 — scope and trust — RATIFIED 2026-05-15* by a Camel PMC maintainer. +The corresponding body tags now read _(maintainer, 2026-05-15)_. For the +record, the ratified positions are: + +* *Q1 (confirmed)* — Blueprint XML (`camel-blueprint`) is trusted route-author + input, exactly equivalent to Spring/Java/YAML DSL in Camel core; the only + in-scope case is camel-karaf itself passing *message data* into Blueprint + bean instantiation. +* *Q2 (confirmed)* — Karaf operators are fully trusted; installing a + feature/bundle or running the deployer is a privileged code-deployment + action, never a camel-karaf vulnerability. +* *Q3 (confirmed)* — camel-karaf does not treat the OSGi bundle boundary as a + security sandbox and does not rely on the OSGi `SecurityManager` / + conditional permissions. +* *Q4 (confirmed)* — the Karaf shell `camel:*` commands are a management + surface (like camel-management/JMX), gated only by the Karaf console / JAAS; + they add no capability beyond DSL/JMX. +* *Q5 (confirmed)* — the single in-scope camel-karaf class is "the OSGi + resolution layer widens, for untrusted message data, a class/bean/component + sink that flat-classpath Camel core had closed". + +*Wave 2 — boundaries of the inherited model — RATIFIED 2026-05-15* by a Camel +PMC maintainer. The corresponding body tags now read _(maintainer, +2026-05-15)_. For the record, the ratified positions are: + +* *Q6 (confirmed)* — no camel-karaf-authored class (`camel-core-osgi`, + `camel-blueprint`, shell) is *itself* a primary deser/XXE/path-traversal/ + header-injection sink; they only resolve names (Q5) or delegate to Camel + core. Backed by a source scan: no `ObjectInputStream`/`readObject`, XML + parser, `TransformerFactory`, `Runtime`/`ProcessBuilder`, + `URLClassLoader`/`defineClass`, `ScriptEngine` or file-write sink in the + authored runtime code; `OsgiTypeConverter` only delegates to Camel core's + `DefaultTypeConverter`. +* *Q7 (confirmed)* — no isolation is promised between bundles co-deployed in + one Karaf instance (shared JVM, service registry, classes subject to + wiring); corollary of Q3. +* *Q8 (confirmed)* — artifact integrity for `mvn:`/`wrap:` feature references + (repository TLS, checksum/PGP, dependency confusion) is + Pax-URL/Karaf/operator responsibility, out of scope for camel-karaf. +* *Q9 (confirmed)* — `tests/`, `tests/examples/`, `archetypes/` are + shipped-but-unsupported and out of model (threat-modeled separately only if + promoted). +* *Q10 (confirmed)* — defects in Karaf / Pax-Web / Pax-URL / the Blueprint + extender / EventAdmin themselves are out of scope; report upstream. A + camel-karaf report must show camel-karaf code is the cause. + +*Wave 3 — operational / lifecycle — RATIFIED 2026-05-15* by a Camel PMC +maintainer. The corresponding body tags now read _(maintainer, 2026-05-15)_. +For the record, the ratified positions are: + +* *Q11 (confirmed)* — the lag between an Apache Camel security release and the + matching camel-karaf release is expected and is not itself a camel-karaf + vulnerability; no fixed SLA is committed (the remediation is the version + upgrade via the upgrade tooling). +* *Q12 (confirmed)* — the Camel security-policy enforcement framework + (`camel.main.profile`, `insecure:*`) behaves as in core; camel-karaf neither + disables nor replaces it under Blueprint/OSGi bootstrapping. +* *Q13 (confirmed)* — the `camel-core-osgi` host-effect inventory is accurate + and complete: it registers OSGi service listeners, publishes each + `CamelContext` as an OSGi service (`OsgiCamelContextPublisher`), and emits + EventAdmin events when EventAdmin is present (`OsgiEventAdminNotifier`); it + opens no sockets, spawns no processes, installs no signal handlers and + starts no threads of its own. Verified by source scan. +* *Q14 (confirmed)* — there are no camel-karaf-specific thread-safety / + reentrancy caveats beyond Camel core's plus OSGi service dynamics. +* *Q15 (confirmed)* — no camel-karaf compile-time flag toggles a security + property; every Maven profile is build / release / documentation plumbing. + Verified against the project poms. + +*Wave 4 — meta — RATIFIED 2026-05-15* by a Camel PMC maintainer: + +* *Q16 (confirmed)* — this page is the canonical camel-karaf security model; + it links to the Apache Camel Security Model for all data-plane classes + rather than being merged into it or sitting alongside a second authority. +* *Q17 (confirmed)* — camel-karaf has no separate entry at + `security.apache.org/projects/`; it is governed entirely by the Apache Camel + security process and advisory index. Verified against the `apache/security-site` + project-coordinates. + +== Reporting a vulnerability + +camel-karaf uses the Apache Camel / ASF vulnerability reporting process. + +* Read link:https://camel.apache.org/security/[Apache Camel Security] and the + repository `SECURITY.md`. +* Email the Apache Camel private security list with a description, affected + camel-karaf and Camel versions, and a proof of concept demonstrating the + trust-boundary breach (and stating whether the defect is in camel-karaf code + or in a packaged Camel component). +* Do not open a public issue, pull request or mailing-list post about an + unpublished vulnerability. + +Reports matching <<security-properties>> are triaged on the private list and, +if confirmed, fixed in a coordinated camel-karaf release and published as a +CVE. Reports matching <<out-of-scope>> or <<not-provided>> are closed with a +reference to this document; data-plane reports against a packaged component +are redirected to the Apache Camel process. + +== Related documents + +* https://github.com/apache/camel/blob/main/docs/user-manual/modules/ROOT/pages/security-model.adoc[Apache + Camel Security Model] — *canonical* for all data-plane vulnerability classes; + this page is the Karaf-specific delta only. +* link:https://camel.apache.org/security/[Apache Camel Security] — the public + advisory index and reporting process (covers camel-karaf). +* `SECURITY.md` (repository root) — the GitHub-rendered security pointer. +* xref:index.adoc[Support for Apache Karaf] — what camel-karaf is and how it + installs into Karaf.
