[
https://issues.apache.org/jira/browse/CASSPYTHON-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125624#comment-18125624
]
Bret McGuire commented on CASSPYTHON-29:
----------------------------------------
So I almost entirely disagree with the idea that arbitrary keys in a STARTUP
message are a problem.
My first comment would be that by any reasonable reading this is actually the
correct implementation of the spec. The v5 spec [clearly
indicates|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L473-L487]
that the body of a STARTUP message is a stringmap of options. It then
describes a set of "(p)ossible" options which clearly is not meant to limit the
full set of options that can be used. Only one such option (CQL_VERSION) is
called out as required; everything else is optional. This doesn't mean a
driver is _required_ to support arbitrary fields here but it seems pretty clear
that's the intention of the spec.
It's also worth noting that the v5 spec _already_ explicitly supports the
ability to send ad-hoc key/value pairs with requests and responses via the
[custom payload
feature|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L294-L302]
for requests and responses. These options are clearly _not_ considered a
security thread; in fact they're ignored by the server by default. Why should
free-form options in STARTUP messages be treated differently?
Secondly, if we consider the addition of extra keys and values to be a security
threat (which I'm not convinced of) then not exposing API options to enable
this feature is not a robust way to defend against such attacks. The proper
approach for such a concern would seem to be to limit the feasibility of adding
additional fields to the STARTUP message or having the server enforce a policy
of some kind on such props if it chose to do so. That way you'd get rigorous
enforcement of a common security policy across clients.
I do agree that there's a merging of metadata and keys which actually affect
operations here; [~bschoeni]'s example of COMPRESSION is a useful one. But I
don't see this as an argument that we have to limit the API to account for this
distinction. We can accept a free-form key/value map as input and then
override any keys that have to contain certain values before sending it out.
We should do so with CQL_VERSION (so that a user can't set it to some random
value) and we should do something similar with COMPRESSION (based on context).
We can make the API docs clear that the map isn't a guarantee and that
overrides might happen in a few select cases. We can also log the fact that
those values are being overridden at runtime. But again this doesn't seem like
an argument not to expose the API.
Why do I care this much? I'll extend the original argument by making the
observation that the ability to extend options to STARTUP messages (ideally
without a new driver release) has come up in relation in a couple recent
feature discussions. It was an option for maintaining consistency between
client and server IDs when considering OpenTelemetry (although the per-request
custom payload worked better in that case). It was also an option that was
considered for CEP-59 support. Having the availability to test those options
directly without a new Java driver build that had API options added for
specific keys would've been helpful.
APPLICATION_NAME and APPLICATION_VERSION themselves are also useful examples of
this. DataStax added these fields to support a specific product (Insights) and
were able to do so because they controlled the drivers at the time. The
drivers are now managed by the ASF... why shouldn't other users be able to
setup similar use cases without having to submit a patch and wait for a new
release just to get the ability to _set_ their custom key or keys?
For the record: I also disagree with the idea of keeping APPLICATION_NAME and
APPLICATION_VERSION and repurposing them. These names won't have a clear use
in all applications and if that's the case then they're just sticking around
for historical reasons... which doesn't seem like a good idea. Far better to
give users the ability to control exactly what keys make sense for their use
case... which is exactly what we get from a free-form key/value map.
> 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]
