[
https://issues.apache.org/jira/browse/CASSPYTHON-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127172#comment-18127172
]
Brad Schoening edited comment on CASSPYTHON-29 at 10/15/26 3:47 PM:
--------------------------------------------------------------------
[~absurdfarce] [~bohdansiryk] [~jeremiah] I agree that {{system_views.clients}}
should be diligent about non-printable characters regardless of what we decide
here, and if that were the only exposure path I’d be much closer to your
position. My concern is that it isn’t the only path.
The same client-supplied map also reaches {{nodetool clientstats}} and the JMX
client metrics via {{{}ConnectedClient.asMap(){}}}, and potentially the logs.
Sanitizing at the {{system_views.clients}} display layer leaves those other
sinks untouched, so we’d be fixing one consumer and signing every other
consumer up to repeat the same work. A single server-side policy on what gets
stored is the only place that covers all of them at once.
{{ConnectedClient.asMap()}} is a concrete example: it joins the entries as
{{k=v, k=v}} with no escaping, so a value containing {{, foo=bar}} is
indistinguishable from a separate option in that output.
I’d also highlight that STARTUP is processed before authentication. Up to
{{native_transport_max_frame_size}} (16 MB by default) is accepted and the
options are retained on the server before the connection is authed. An
unauthenticated client can therefore set arbitrary values that operators later
see in the virtual table, {{{}nodetool{}}}, and JMX — even if it never logs in
— for as long as the connection stays open.
So before we expose arbitrary parameters, I’d suggest the server be hardened to
constrain the STARTUP options:
* allow only printable UTF8 characters
* set a max length on each key and value (80 characters, or some reasonable
bound)
* cap the number of options to keep the frame small (maybe max 20 keys)
* require keys to be unique, to protect against duplicate options
On the spec point: it does say strings are UTF-8, but the STARTUP section reads
“T{_}he body is a [string map] of options. Possible options are: …{_}” followed
by a fixed list. That phrasing reads to me like an enumeration of defined keys
rather than an open-ended map with {{APPLICATION_NAME}} and
{{APPLICATION_VERSION}} treated as undocumented additions to it. If we’re going
to formally support an arbitrary map, I’d argue that’s a spec change worth
making explicitly, and constraining the contents at the same time is a
reasonable part of that.
was (Author: bschoeni):
[~absurdfarce] [~bohdansiryk] [~jeremiah] I agree that {{system_views.clients}}
should be diligent about non-printable characters regardless of what we decide
here, and if that were the only exposure path I’d be much closer to your
position. My concern is that it isn’t the only path.
The same client-supplied map also reaches {{nodetool clientstats}} and the JMX
client metrics via {{{}ConnectedClient.asMap(){}}}, and potentially the logs.
Sanitizing at the {{system_views.clients}} display layer leaves those other
sinks untouched, so we’d be fixing one consumer and signing every other
consumer up to repeat the same work. A single server-side policy on what gets
stored is the only place that covers all of them at once.
{{ConnectedClient.asMap()}} is a concrete example: it joins the entries as
{{k=v, k=v}} with no escaping, so a value containing {{, foo=bar}} is
indistinguishable from a separate option in that output.
I’d also highlight that STARTUP is processed before authentication. Up to
{{native_transport_max_frame_size}} (16 MB by default) is accepted and the
options are retained on the server before the connection is authed. An
unauthenticated client can therefore set arbitrary values that operators later
see in the virtual table, {{{}nodetool{}}}, and JMX — even if it never logs in
— for as long as the connection stays open.
So before we expose arbitrary parameters, I’d suggest the server be hardened to
constrain the STARTUP options:
* allow only printable ASCII characters
* set a max length on each key and value (80 characters, or some reasonable
bound)
* cap the number of options to keep the frame small (maybe max 20 keys)
* require keys to be unique, to protect against duplicate options
On the spec point: it does say strings are UTF-8, but the STARTUP section reads
“T{_}he body is a [string map] of options. Possible options are: …{_}” followed
by a fixed list. That phrasing reads to me like an enumeration of defined keys
rather than an open-ended map with {{APPLICATION_NAME}} and
{{APPLICATION_VERSION}} treated as undocumented additions to it. If we’re going
to formally support an arbitrary map, I’d argue that’s a spec change worth
making explicitly, and constraining the contents at the same time is a
reasonable part of that.
> Allow user to specify arbitrary parameters for STARTUP message
> --------------------------------------------------------------
>
> Key: CASSPYTHON-29
> URL: https://issues.apache.org/jira/browse/CASSPYTHON-29
> Project: Apache Cassandra Python driver
> Issue Type: Improvement
> Components: Core
> Reporter: Swathi Sekar
> Assignee: Bohdan Siryk
> Priority: Normal
> Fix For: 4.0.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Modify the driver to allow sending arbitrary STARTUP message options.
> Proposed design:
> - Add `extra_startup_options` param to Cluster constructor.
> - Thread it through Cluster -> connection setup (cluster.py) ->
> StartupMessage.
> - Define clear precedence/conflict behavior when duplicate/conflicting
> options are passed into the StartupMessage constructor.
> *Note:*
> This Jira was originally created for sending the client's application name
> and version as `APPLICATION_NAME` /
> `APPLICATION_VERSION` options in the STARTUP message, which is tied to the
> now-defunct DataStax Insights offering.
> Since the Java driver (5.0.0) and eventually C/C++ driver (3.0.0) are
> removing withApplicationName()/withApplicationVersion() entirely, this ticket
> has been updated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
