[
https://issues.apache.org/jira/browse/CASSPYTHON-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127627#comment-18127627
]
Bret McGuire commented on CASSPYTHON-29:
----------------------------------------
Apologies, you guys raise a fair point. My question shouldn't have been "if we
knew that system_views.clients were very diligent..."; it should've been "if we
knew _the server_ were very diligent...". I completely agree with [~bschoeni]
(and I think [~bohdansiryk] as well) that some kind of unified server-side
policy that is applied to all spots where this information is accessed is the
right way to approach this, so a hearty +1 there.
I don't agree that there's any reason to delay implementing changes on the
driver to enable arbitrary key/value pairs until the server is hardened. As
has been mentioned a couple times on this ticket there are almost certainly
existing drivers out there who support setting such ad-hoc values, and even if
there aren't it's trivial to modify the open-source drivers to do so (as
[~jeremiah] mentioned). And if that's the case there's no reason to correlate
work on this ticket to some server-side change; vectors for the exploit already
exist (or can be trivially made). We're not increasing security by keeping
this work out of the next driver release(s).
Regarding the language in the spec: my reading of section 4.1.1 has always been
that the options called out in the spec are examples of things which can (and
in the case of CQL_VERSION _must_) appear in the STARTUP message but that the
list is not intended to be exhaustive or limiting. If the intent was for
something stronger I would've expected language more like "Valid keys for this
stringmap are limited to..." or something similar. The comments [~bohdansiryk]
mentioned on CASSANDRA-16378 do strongly support this reading as well. Either
way, it's very clear that the DataStax drivers have been passing along keys
which are _not_ in this list (in the form of APPLICATION_NAME and
APPLICATION_VERSION) for some time and this has clearly not been regarded as a
violation of the spec. I'd be a strong +1 to any effort to add clarifying
language to the spec to make this point clearer but given the record above I
don't see any reason to delay work on this ticket while that issue is sorted
out.
> 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]
