fix(#729): escape names embedded in OSGi service filters - #738
Open
oscerd wants to merge 1 commit into
Open
Conversation
Six lookups in camel-core-osgi built a service filter by concatenating a
name straight into it: OsgiBeanRepository (name= and service.pid=),
OsgiComponentResolver (component=), OsgiLanguageResolver (language= and
resolver=) and OsgiDataFormatResolver (dataformat=).
Filter metacharacters in the name were therefore read as filter syntax
rather than matched as text. A name of "*" becomes a presence assertion
matching every registered service, and since each site takes refs[0] the
lookup returned an arbitrary service instead of not resolving. A name
containing ")(" made the framework reject the filter, faulting the
exchange with a syntax error instead of a clean not-found.
Route this through OsgiFilterHelper.createFilter, which escapes the value
first. Escaping only: the FQCN and service.pid interpretations in
lookupByName are the documented purpose of the class and are left alone,
since narrowing them would change behaviour for existing deployments.
getServiceReference(name) at OsgiBeanRepository:80 takes an exact
interface name rather than a filter, so it needs nothing.
Note the escaping is the OSGi filter grammar's backslash-before-character
form, not the RFC 4515 "\2a" hex form - an OSGi Filter reads the latter as
the two literal characters 2a. The tests caught this: they assert against
a real FrameworkUtil.createFilter, so they check the filter actually stops
matching rather than just that a string was rewritten.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #729
What
Six lookups in
camel-core-osgibuilt an OSGi service filter by concatenating aname straight into it:
OsgiBeanRepository:60(name=<name>)OsgiBeanRepository:83(service.pid=<name>)OsgiComponentResolver:53(component=<name>)OsgiLanguageResolver:62(language=<name>)OsgiLanguageResolver:82(resolver=<name>)OsgiDataFormatResolver:62(dataformat=<name>)Filter metacharacters in the name were read as filter syntax rather than matched
as text. A name of
*becomes a presence assertion matching every registeredservice, and since each site takes
refs[0], the lookup returned an arbitraryservice instead of not resolving. A name containing
)(made the frameworkreject the filter, faulting the exchange with a syntax error rather than giving
a clean not-found.
How
All six go through
OsgiFilterHelper.createFilter(key, value), which escapesthe value before embedding it.
Escaping only. The FQCN and
service.pidinterpretations inlookupByNameare the documented purpose of
OsgiBeanRepositoryand are left intact —narrowing them would be a behaviour change for existing deployments, and is a
separate discussion.
getServiceReference(name)atOsgiBeanRepository:80takes an exact interface name rather than a filter, so it needs nothing.
For every legitimate name (
jms,aws2-s3,org.apache.camel.MyBean, …) thehelper returns the string unchanged, so there is no behaviour change on the
normal path.
A correction worth flagging
#729 suggested RFC 4515 escaping. That is the wrong grammar for OSGi and I
had written it that way first — the tests caught it.
The OSGi Core specification defines its own filter grammar in which a value
escapes
(,),*and\with a single preceding backslash. The RFC 4515hex form
\2ais read by an OSGiFilteras the two literal characters2a,so escaping
*as\2awould have stopped a wildcard matching everything butwould also have stopped it matching a service genuinely named
*— silentlywrong rather than safe. The helper now emits
\*,\(,\),\\and thejavadoc says why.
Tests
OsgiFilterHelperTest(13 cases). The important ones do not assert on therewritten string — they build a real
FilterviaFrameworkUtil.createFilterand check what it actually matches:
(name=*)escaped no longer matchesname=someRegisteredBean, but stillmatches a service whose name really is
*x)(objectClass=org.apache.karaf.features.FeaturesServiceproducesa valid filter that matches neither an unrelated
namenor the injectedobjectClassclause, and matches only the literal name)(no longer makescreateFilterthrow(name=*)unescaped does match anarbitrary service) so the regression is visible if the escaping is ever lost
(25 = 13 new + the 12 pre-existing
camel-core-osgitests, all still passing.)Also adds the
junit-jupiter-paramstest dependency.Claude Code on behalf of Andrea Cosentino