[
https://issues.apache.org/jira/browse/CASSPYTHON-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125444#comment-18125444
]
Brad Schoening edited comment on CASSPYTHON-29 at 10/9/26 9:31 AM:
-------------------------------------------------------------------
I have concerns about the scope of CASSPYTHON-29 itself. I see there was
earlier discussion of the design on the Jira which unfortunately, I hadn't been
following.
* The justification doesn't support "arbitrary." The ticket's rationale is
that STARTUP options are visible in {{system_views.clients}} since 4.1. That's
an observability use case: letting operators identify which application owns a
connection. It needs one or two well-defined, operator-facing values. It
doesn't need an open-ended map of keys and values passed straight to the server.
* It creates an attack surface for later changes. Once the driver accepts an
arbitrary map, natural follow-ups could be to populate it from environment
variables, connection strings, or config files. Each of those moves control of
STARTUP contents further toward less-trusted inputs. I'd rather not establish a
general-purpose channel whose value is marginal today but whose risk grows with
each extension.
* The STARTUP map isn't just metadata. The server interprets some keys
({{{}CQL_VERSION{}}}, {{{}COMPRESSION{}}}, {{{}NO_COMPACT{}}},
{{{}THROW_ON_OVERLOAD{}}}) as settings, and the protocol may add more. A
pass-through map adds arbitrary keys that the driver doesn't know about and
can't reason about.
* Exposure of whatever users naively put in it. {{system_views.clients}} is
often readable fairly broadly. A free-form map allows people to put tokens,
hostnames, user identifiers, or other sensitive PII data where many readers can
see it.
Why not keep *application_name* and *application_version* parameters (and
optionally {*}client_id{*}), mapped to the same keys the Java driver uses.
Sure, Insight is obsolete, but the use of these keys could be repurposed. Each
could be validated at construction as a bounded string, e.g. up to 80 printable
ASCII characters. That covers the observability use case behind
CASSANDRA-16378, has a fixed and reviewable footprint, and can't be used to
alter server behavior.
For comparison, the Postgres Java & Python drivers do exactly this:
{quote}application_name (string)
The application_name can be any string of less than NAMEDATALEN characters (64
characters in a standard build). It is typically set by an application upon
connection to the server. The name will be displayed in the pg_stat_activity
view and included in CSV log entries. It can also be included in regular log
entries via the
[log_line_prefix|https://www.postgresql.org/docs/17/runtime-config-logging.html#GUC-LOG-LINE-PREFIX]
parameter. Only printable ASCII characters may be used in the application_name
value. Other characters are replaced with [C-style hexadecimal escapes].
[https://www.postgresql.org/docs/17/runtime-config-logging.html#GUC-APPLICATION-NAME]
{quote}
was (Author: bschoeni):
I have concerns about the scope of CASSPYTHON-29 itself. I see there was
earlier discussion of the design on the Jira which unfortunately, I hadn't been
following.
* The justification doesn't support "arbitrary." The ticket's rationale is
that STARTUP options are visible in {{system_views.clients}} since 4.1. That's
an observability use case: letting operators identify which application owns a
connection. It needs one or two well-defined, operator-facing values. It
doesn't need an open-ended map of keys and values passed straight to the server.
* It creates an attack surface for later changes. Once the driver accepts an
arbitrary map, natural follow-ups could be to populate it from environment
variables, connection strings, or config files. Each of those moves control of
STARTUP contents further toward less-trusted inputs. I'd rather not establish a
general-purpose channel whose value is marginal today but whose risk grows with
each extension.
* The STARTUP map isn't just metadata. The server interprets some keys
({{{}CQL_VERSION{}}}, {{{}COMPRESSION{}}}, {{{}NO_COMPACT{}}},
{{{}THROW_ON_OVERLOAD{}}}) as settings, and the protocol may add more. A
pass-through map adds arbitrary keys that the driver doesn't know about and
can't reason about.
* Exposure of whatever users naively put in it. {{system_views.clients}} is
often readable fairly broadly. A free-form map allows people to put tokens,
hostnames, user identifiers, or other sensitive PII data where many readers can
see it.
Why not keep *application_name* and *application_version* parameters (and
optionally {*}client_id{*}), mapped to the same keys the Java driver uses.
Sure, Insight is obsolete, but the use of these keys could be repurposed. Each
could be validated at construction as a bounded string, e.g. up to 80 printable
ASCII characters. That covers the observability use case behind
CASSANDRA-16378, has a fixed and reviewable footprint, and can't be used to
alter server behavior.
For comparison, the Postgres Java & Python drivers do exactly this:
{quote}application_name (string)
The application_name can be any string of less than NAMEDATALEN characters (64
characters in a standard build). It is typically set by an application upon
connection to the server. The name will be displayed in the pg_stat_activity
view and included in CSV log entries. It can also be included in regular log
entries via the
[log_line_prefix|https://www.postgresql.org/docs/17/runtime-config-logging.html#GUC-LOG-LINE-PREFIX]
parameter. Only printable ASCII characters may be used in the application_name
value. Other characters are replaced with [C-style hexadecimal escapes].
[https://www.postgresql.org/docs/17/runtime-config-logging.html#GUC-APPLICATION-NAME]
{quote}
> 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: 0.5h
> 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]
