Re: [VOTE] Release dtest-api 0.0.8

[Oleksandr Petrov]

+1

On Fri, Jul 9, 2021 at 12:29 PM Mick Semb Wever  wrote:

> Proposing the test build of in-jvm dtest API 0.0.8 for release.
>
> Repository:
>
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.8
>
> Candidate SHA:
>
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/db3cdf5823fbc49c6b5c53dc2b15330d3883fd09
> tagged with 0.0.8
>
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1240/org/apache/cassandra/dtest-api/0.0.8/
>
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>
>
> Changes since last release:
>   * CASSANDRA-16649: Update Versions for trunk as 4.1 and new release
> branch cassandra-4.0
>   * CASSANDRA-16649: Introduce SemVer4j for version representation, parsing
> and handling
>
> The vote will be open for 24 hours. Everyone who has tested the build
> is invited to vote. Votes by PMC members are considered binding. A
> vote passes if there are at least three binding +1s.
>


-- 
alex p

Re: [VOTE] Release dtest-api 0.0.8

[Mick Semb Wever]

>
> The vote will be open for 24 hours. Everyone who has tested the build
> is invited to vote. Votes by PMC members are considered binding. A
> vote passes if there are at least three binding +1s.
>


+1

Re: [VOTE] Release dtest-api 0.0.8

[Benjamin Lerer]

+1

Le lun. 12 juil. 2021 à 11:10, Mick Semb Wever  a écrit :

> >
> > The vote will be open for 24 hours. Everyone who has tested the build
> > is invited to vote. Votes by PMC members are considered binding. A
> > vote passes if there are at least three binding +1s.
> >
>
>
> +1
>

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Benjamin Lerer]

>
> In the context of your latest answers on JIRA - your interface makes sense
> to me, I just want to be sure that we will not forget to add anything which
> would a respective implementator need in the future and could not use
> because it is just not exposed.


I do not believe that we can build the perfect interface. Sadely, it is
impossible to know what future implementations will require. Outside of
the  obvious issues that we can think of right now, I believe that we will
just have to find some solutions at the time where the problems arise.

The thread is right now going into technical areas that could be discussed
on the PR later on. It might be a sign that there are no high level
concerns with the CEP and that we should simply trigger the vote.
If nobody disagrees, I will start the vote tomorrow.



Le sam. 10 juil. 2021 à 07:05, Mick Semb Wever  a écrit :

> Thanks for bringing this back to the ML Maulin.
> Very much appreciated.
>
> On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada 
> wrote:
>
> > Thanks Stefan for the pointer for the 'examples' directory. Will invest
> > time in coming up with a reference custom implementation.
> >
> > For your other comments around common encryption options, I agree with
> you
> > on a challenge in order to prevent secure information getting leaked in
> > logs. Let me create a separate branch and show how interface will change
> > with keeping Common Encryption options + map instead of just the map.
> >
> > Thanks
> > Maulin
> >
> > On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
> maulin.vasav...@gmail.com>
> > wrote:
> >
> > > Stefan Miklosovic
> > > 
> > >
> > > Hi MAULIN VASAVADA
> > > , few
> more
> > > observations. I see that you have commented again on JIRA and I am
> > starting
> > > to be confused where to comment in relation to recent thread we had
> about
> > > this so I am letting you know that I am ultimately using this
> > communication
> > > channel for discussion.
> > >
> > > In the context of your latest answers on JIRA - your interface makes
> > sense
> > > to me, I just want to be sure that we will not forget to add anything
> > which
> > > would a respective implementator need in the future and could not use
> > > because it is just not exposed. I am not completely sure how to solve
> > this
> > > but I think that we just have to stick to our gut feeling that the
> > solution
> > > proposed will cover the most scenarios.
> > >
> > > If we do not feel safe, my idea was to show yet another implementation
> > > where the possibility we would left a user behind is minimised.
> > Otherwise,
> > > without breaking older implementations used in future releases, we
> could
> > > only introduce methods which would have default implementations.
> > >
> > > I prefer to have a map instead of common encryption options. On the
> other
> > > hand, I can imagine that the custom implementation would try to bypass
> > some
> > > credentials into it (for example how to connect to a respective source
> of
> > > these keystores / truststores) and if we ever decided to have some kind
> > of
> > > a tooling around this, e.g. in nodetool, to get a status of "how ssl is
> > > configured", we might unintentionally leak security sensitive
> information
> > > (credentials) by displaying them in plaintext in such tooling. We are
> > using
> > > JMX for this (I might expand on this if you are not familiar with that
> > > mechanism of getting runtime info from Cassandra via JMX). Hence what
> we
> > > might do is to actually not expose that map at all. We are not exposing
> > > this kind of information yet in runtime and I do not think we actually
> > have
> > > a need for that I just find it important to say.
> > >
> > > I like the fact that configuration parameters for an implementation are
> > > coupled with that factory configuration and it is just a basic map.
> Since
> > > implementations are getting their EncryptionOptions + map of customs, I
> > > prefer this instead of putting there whole map of parameters because
> then
> > > you are just again "parsing it" from map in respective constructors.
> > There
> > > is nothing wrong with how this is done in your original PR, I would
> say.
> > > The very same pattern of "maps" may be found across the code base, e.g.
> > > auditing and similar.
> > >
> > > On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
> > maulin.vasav...@gmail.com>
> > > wrote:
> > >
> > >> Stefan Miklosovic
> > >> 
> > >>
> > >> I ve taken a look too. Added some comments to PR.
> > >>
> > >> It would be awesome if we see some 3rd party implementation of this in
> > >> action so we know it indeed works as intended. It is strange to just
> > code
> > >> up an interface by default logic for which it works but there isnt any
> > >> (public) example how to do yet anot

[VOTE][RESULT] Release dtest-api 0.0.8

[Mick Semb Wever]

Vote passes with three binding +1 and no vetos.

[ANNOUNCE] Apache Cassandra 4.0.0 test artifact available (take2)

[Mick Semb Wever]

The test build of Cassandra 4.0.0 is available.

sha1: 69b8cc5cecc196fddb549f2edf01d962e7ef2dae
Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1241/org/apache/cassandra/cassandra-all/4.0.0/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/

A vote of this test build will be initiated within the next 24 hours.
Please start testing, feedback and vetoes are welcome in advance of the
vote start.

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
[2]: NEWS.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

Thank you Benjamin. Sounds good to me.

I feel if we leave full control of creating SSL's context (including
ciphers, accepted protocols values etc) to the interface it would work.
There are some other requirements people run into like customizing X 509
cert validations (SPIFFE
), using
different SSL Providers (like Bouncy Castle, Boring SSL etc) altogether
which in my opinion can be better served with exploration of JSSE Providers
(java's security.provider configuration) instead of trying to customize
just the SSL Context. However, leaving full control with the SSL context
factory interface may mean supporting 'Map' as modelling the configuration
vs keeping 'CommonEncryptionOption' but that would again go into more
technical discussion so we can keep it separate.

Thanks
Maulin

On Mon, Jul 12, 2021 at 3:27 AM Benjamin Lerer  wrote:

> >
> > In the context of your latest answers on JIRA - your interface makes
> sense
> > to me, I just want to be sure that we will not forget to add anything
> which
> > would a respective implementator need in the future and could not use
> > because it is just not exposed.
>
>
> I do not believe that we can build the perfect interface. Sadely, it is
> impossible to know what future implementations will require. Outside of
> the  obvious issues that we can think of right now, I believe that we will
> just have to find some solutions at the time where the problems arise.
>
> The thread is right now going into technical areas that could be discussed
> on the PR later on. It might be a sign that there are no high level
> concerns with the CEP and that we should simply trigger the vote.
> If nobody disagrees, I will start the vote tomorrow.
>
>
>
> Le sam. 10 juil. 2021 à 07:05, Mick Semb Wever  a écrit :
>
> > Thanks for bringing this back to the ML Maulin.
> > Very much appreciated.
> >
> > On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada  >
> > wrote:
> >
> > > Thanks Stefan for the pointer for the 'examples' directory. Will invest
> > > time in coming up with a reference custom implementation.
> > >
> > > For your other comments around common encryption options, I agree with
> > you
> > > on a challenge in order to prevent secure information getting leaked in
> > > logs. Let me create a separate branch and show how interface will
> change
> > > with keeping Common Encryption options + map instead of just the map.
> > >
> > > Thanks
> > > Maulin
> > >
> > > On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
> > maulin.vasav...@gmail.com>
> > > wrote:
> > >
> > > > Stefan Miklosovic
> > > > 
> > > >
> > > > Hi MAULIN VASAVADA
> > > > , few
> > more
> > > > observations. I see that you have commented again on JIRA and I am
> > > starting
> > > > to be confused where to comment in relation to recent thread we had
> > about
> > > > this so I am letting you know that I am ultimately using this
> > > communication
> > > > channel for discussion.
> > > >
> > > > In the context of your latest answers on JIRA - your interface makes
> > > sense
> > > > to me, I just want to be sure that we will not forget to add anything
> > > which
> > > > would a respective implementator need in the future and could not use
> > > > because it is just not exposed. I am not completely sure how to solve
> > > this
> > > > but I think that we just have to stick to our gut feeling that the
> > > solution
> > > > proposed will cover the most scenarios.
> > > >
> > > > If we do not feel safe, my idea was to show yet another
> implementation
> > > > where the possibility we would left a user behind is minimised.
> > > Otherwise,
> > > > without breaking older implementations used in future releases, we
> > could
> > > > only introduce methods which would have default implementations.
> > > >
> > > > I prefer to have a map instead of common encryption options. On the
> > other
> > > > hand, I can imagine that the custom implementation would try to
> bypass
> > > some
> > > > credentials into it (for example how to connect to a respective
> source
> > of
> > > > these keystores / truststores) and if we ever decided to have some
> kind
> > > of
> > > > a tooling around this, e.g. in nodetool, to get a status of "how ssl
> is
> > > > configured", we might unintentionally leak security sensitive
> > information
> > > > (credentials) by displaying them in plaintext in such tooling. We are
> > > using
> > > > JMX for this (I might expand on this if you are not familiar with
> that
> > > > mechanism of getting runtime info from Cassandra via JMX). Hence what
> > we
> > > > might do is to actually not expose that map at all. We are not
> exposing
> > > > this kind of information yet in runtime and I do not think we
> actually
> > > have
> > > > a need for that I just find it important to say.
> > > >
> > > > I like the fact that co

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Ekaterina Dimitrova]

Hi everyone,

Reading the thread I feel we are all more or less on the same page.

My personal line of thinking:
1) I really like Benedict’s idea of some kind of cheat sheet
2) I think some kind of PoC PR, when/if needed, sounds reasonable. Probably
It can help in some cases the author to reconsider  or even explain better
some suggestions/decisions. In that sense, I think I agree with Maulin that
probably Jira ticket after voted CEP is a good idea. I think that when we
put PR in a Jira ticket (at least I as a creature of habit) we start
thinking of more diligent reviews and might forget it is still unapproved
CEP and get into details that doesn’t really matter at this point in time.
But that might be only me. :-)

Best regards,
Ekaterina

On Mon, 12 Jul 2021 at 15:47, Maulin Vasavada 
wrote:

> Thank you Benjamin. Sounds good to me.
>
> I feel if we leave full control of creating SSL's context (including
> ciphers, accepted protocols values etc) to the interface it would work.
> There are some other requirements people run into like customizing X 509
> cert validations (SPIFFE
> ),
> using
> different SSL Providers (like Bouncy Castle, Boring SSL etc) altogether
> which in my opinion can be better served with exploration of JSSE Providers
> (java's security.provider configuration) instead of trying to customize
> just the SSL Context. However, leaving full control with the SSL context
> factory interface may mean supporting 'Map' as modelling the configuration
> vs keeping 'CommonEncryptionOption' but that would again go into more
> technical discussion so we can keep it separate.
>
> Thanks
> Maulin
>
> On Mon, Jul 12, 2021 at 3:27 AM Benjamin Lerer  wrote:
>
> > >
> > > In the context of your latest answers on JIRA - your interface makes
> > sense
> > > to me, I just want to be sure that we will not forget to add anything
> > which
> > > would a respective implementator need in the future and could not use
> > > because it is just not exposed.
> >
> >
> > I do not believe that we can build the perfect interface. Sadely, it is
> > impossible to know what future implementations will require. Outside of
> > the  obvious issues that we can think of right now, I believe that we
> will
> > just have to find some solutions at the time where the problems arise.
> >
> > The thread is right now going into technical areas that could be
> discussed
> > on the PR later on. It might be a sign that there are no high level
> > concerns with the CEP and that we should simply trigger the vote.
> > If nobody disagrees, I will start the vote tomorrow.
> >
> >
> >
> > Le sam. 10 juil. 2021 à 07:05, Mick Semb Wever  a écrit
> :
> >
> > > Thanks for bringing this back to the ML Maulin.
> > > Very much appreciated.
> > >
> > > On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada <
> maulin.vasav...@gmail.com
> > >
> > > wrote:
> > >
> > > > Thanks Stefan for the pointer for the 'examples' directory. Will
> invest
> > > > time in coming up with a reference custom implementation.
> > > >
> > > > For your other comments around common encryption options, I agree
> with
> > > you
> > > > on a challenge in order to prevent secure information getting leaked
> in
> > > > logs. Let me create a separate branch and show how interface will
> > change
> > > > with keeping Common Encryption options + map instead of just the map.
> > > >
> > > > Thanks
> > > > Maulin
> > > >
> > > > On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
> > > maulin.vasav...@gmail.com>
> > > > wrote:
> > > >
> > > > > Stefan Miklosovic
> > > > > 
> > > > >
> > > > > Hi MAULIN VASAVADA
> > > > > ,
> few
> > > more
> > > > > observations. I see that you have commented again on JIRA and I am
> > > > starting
> > > > > to be confused where to comment in relation to recent thread we had
> > > about
> > > > > this so I am letting you know that I am ultimately using this
> > > > communication
> > > > > channel for discussion.
> > > > >
> > > > > In the context of your latest answers on JIRA - your interface
> makes
> > > > sense
> > > > > to me, I just want to be sure that we will not forget to add
> anything
> > > > which
> > > > > would a respective implementator need in the future and could not
> use
> > > > > because it is just not exposed. I am not completely sure how to
> solve
> > > > this
> > > > > but I think that we just have to stick to our gut feeling that the
> > > > solution
> > > > > proposed will cover the most scenarios.
> > > > >
> > > > > If we do not feel safe, my idea was to show yet another
> > implementation
> > > > > where the possibility we would left a user behind is minimised.
> > > > Otherwise,
> > > > > without breaking older implementations used in future releases, we
> > > could
> > > > > only introduce methods which would have default implementations.
> > >

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Berenguer Blasi]

I have gone through the CEP and I have no concerns on voting on it.

In my case a PR helps me pin down and understand better what the CEP
will indeed look like, I like that a lot. So thx Maulin for the detailed
PR with the luxury of all tests and all bells and whistles!. If it were
a CEP of my own though my PR would be with pseudo-code or similar, for
illustration and brainstorming purposes only, just to give enough
context for the voting. That way if my CEP gets declined I haven't
wasted so much effort.

My 2cts.

On 13/7/21 0:25, Ekaterina Dimitrova wrote:
> Hi everyone,
>
> Reading the thread I feel we are all more or less on the same page.
>
> My personal line of thinking:
> 1) I really like Benedict’s idea of some kind of cheat sheet
> 2) I think some kind of PoC PR, when/if needed, sounds reasonable. Probably
> It can help in some cases the author to reconsider  or even explain better
> some suggestions/decisions. In that sense, I think I agree with Maulin that
> probably Jira ticket after voted CEP is a good idea. I think that when we
> put PR in a Jira ticket (at least I as a creature of habit) we start
> thinking of more diligent reviews and might forget it is still unapproved
> CEP and get into details that doesn’t really matter at this point in time.
> But that might be only me. :-)
>
> Best regards,
> Ekaterina
>
> On Mon, 12 Jul 2021 at 15:47, Maulin Vasavada 
> wrote:
>
>> Thank you Benjamin. Sounds good to me.
>>
>> I feel if we leave full control of creating SSL's context (including
>> ciphers, accepted protocols values etc) to the interface it would work.
>> There are some other requirements people run into like customizing X 509
>> cert validations (SPIFFE
>> ),
>> using
>> different SSL Providers (like Bouncy Castle, Boring SSL etc) altogether
>> which in my opinion can be better served with exploration of JSSE Providers
>> (java's security.provider configuration) instead of trying to customize
>> just the SSL Context. However, leaving full control with the SSL context
>> factory interface may mean supporting 'Map' as modelling the configuration
>> vs keeping 'CommonEncryptionOption' but that would again go into more
>> technical discussion so we can keep it separate.
>>
>> Thanks
>> Maulin
>>
>> On Mon, Jul 12, 2021 at 3:27 AM Benjamin Lerer  wrote:
>>
 In the context of your latest answers on JIRA - your interface makes
>>> sense
 to me, I just want to be sure that we will not forget to add anything
>>> which
 would a respective implementator need in the future and could not use
 because it is just not exposed.
>>>
>>> I do not believe that we can build the perfect interface. Sadely, it is
>>> impossible to know what future implementations will require. Outside of
>>> the  obvious issues that we can think of right now, I believe that we
>> will
>>> just have to find some solutions at the time where the problems arise.
>>>
>>> The thread is right now going into technical areas that could be
>> discussed
>>> on the PR later on. It might be a sign that there are no high level
>>> concerns with the CEP and that we should simply trigger the vote.
>>> If nobody disagrees, I will start the vote tomorrow.
>>>
>>>
>>>
>>> Le sam. 10 juil. 2021 à 07:05, Mick Semb Wever  a écrit
>> :
 Thanks for bringing this back to the ML Maulin.
 Very much appreciated.

 On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada <
>> maulin.vasav...@gmail.com
 wrote:

> Thanks Stefan for the pointer for the 'examples' directory. Will
>> invest
> time in coming up with a reference custom implementation.
>
> For your other comments around common encryption options, I agree
>> with
 you
> on a challenge in order to prevent secure information getting leaked
>> in
> logs. Let me create a separate branch and show how interface will
>>> change
> with keeping Common Encryption options + map instead of just the map.
>
> Thanks
> Maulin
>
> On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
 maulin.vasav...@gmail.com>
> wrote:
>
>> Stefan Miklosovic
>> 
>>
>> Hi MAULIN VASAVADA
>> ,
>> few
 more
>> observations. I see that you have commented again on JIRA and I am
> starting
>> to be confused where to comment in relation to recent thread we had
 about
>> this so I am letting you know that I am ultimately using this
> communication
>> channel for discussion.
>>
>> In the context of your latest answers on JIRA - your interface
>> makes
> sense
>> to me, I just want to be sure that we will not forget to add
>> anything
> which
>> would a respective implementator need in the future and could not
>> use
>> because it is just not exposed. I am not completely sure how to

[VOTE] Release Apache Cassandra 4.0.0

[Mick Semb Wever]

Proposing the test build of Cassandra 4.0.0 for release.

sha1: 69b8cc5cecc196fddb549f2edf01d962e7ef2dae
Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1241/org/apache/cassandra/cassandra-all/4.0.0/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/

The vote will be open for 72 hours (longer if needed). Everyone who has
tested the build is invited to vote. Votes by PMC members are considered
binding. A vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
[2]: NEWS.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative