Fwd: [Discuss] CEP-24 Password validation and generation

[Claude Warren, Jr via dev]

I managed not to send this to the mailaing list...


I don't know the govt spec. but there is a US govt security level where
you are not allowed to inform the user why the login failed.


It seems to me that there are 2 intertwined components being discussed.

1) A component to perform a user password change capability

2) A plugable validation component.

3) A pluggable observability component.

Without a validation component all passwords are valid and provides user
messages for failures.  Validation receives the new password and some
list of old passwords as arguments.  Validation returns a structure
comprising the success/failure, the user message, internal result,
internal result message.

The observability implementations could log the results, send counts to
Grafana, etc.  If there is no observer then no results are presented.


Alternatively the validation could accept the observability component as
an argument and pass the internal result and internal result message
directly to the observability component.

Re: [Discuss] CEP-24 Password validation and generation

[Miklosovic, Stefan]

Hi Claude,

you said: "I don't know the govt spec. but there is a US govt security level 
where you are not allowed to inform the user why the login failed."

I do not think this is the case. Nobody is going to inform a user with existing 
role in the db why he failed to log in, when it comes to this CEP (is not it 
actually already in place? CQLSH says your username / password combo is invalid 
on login already) This CEP has nothing to do with it.

What we have in mind, I think, it is more about informing him about the details 
when the password he tries to set (upon role creation) or change (via role 
alteration), is not valid, based on the policy.

I reckon that what Jeff simply wants to see is a log if such change was 
successful or not. Lets repeat here what Jeff would like to see:

"Password changed for user X, complying with policies (reuse, complexity, 
entropy)"
"ERROR: Password rejected due to policy violation (reuse)"
"ERROR: Password rejected due to policy violation (complexity)"
"ERROR: Password rejected due to policy violation (entropy)"

This is a generalized version of what we already have in place in CEP, we have 
there information like:

Password must be 10 or more characters in length. Password must contain 2 or 
more uppercase characters. Password matches 3 of 4 character rules, but 4 are 
required.
Password matches one of 5 previous passwords.
Password must be 12 or more characters in length

Now, I have to admit that the information we provide above, in contrast of what 
Jeff mentioned, is quite verbose. It is questionable whether we should be so 
specific or whether more generalized version is enough.

Maybe two versions of the logs would be the most appropriate - ours (more 
detailed) would be returned to a user in cqlsh as a warning / error after 
unsuccessful query execution but the messages Jeff mentioned would be written 
in system logs via slf4j. So we would be detailed for a user but general for 
auditing purposes.

Do you think this makes sense to you all? I think this is want you said, more 
or less, in your middle paragraph, just formulated differently.

I agree with Jackson with the password meter e-mail. After all, if somebody 
really wants that to happen, since our solution is pluggable, people can 
implement their own password-meter-based solution if they find it necessary.

To fail a password when it is reused (or found among previous n). I am on the 
edge here. I understand what Josh is telling, that we can go just so far when 
it comes to prevent people from doing wrong things, maybe increasing the 
password history to 20 last passwords would be enough. Anyway, I plan to make 
this historical password verification optional so it might be turned on / off 
on demand.

Finally, when it comes to password dictionaries. This might be included in the 
CEP but I would keep it out for the very first implementation and it can be 
finished afterwards in some other commit. I do not find it absolutely necessary 
to do it right now.

Regards,

Stefan


From: Claude Warren, Jr via dev 
Sent: Thursday, October 13, 2022 9:44
To: dev@cassandra.apache.org
Subject: Fwd: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




I managed not to send this to the mailaing list...


I don't know the govt spec. but there is a US govt security level where
you are not allowed to inform the user why the login failed.


It seems to me that there are 2 intertwined components being discussed.

1) A component to perform a user password change capability

2) A plugable validation component.

3) A pluggable observability component.

Without a validation component all passwords are valid and provides user
messages for failures.  Validation receives the new password and some
list of old passwords as arguments.  Validation returns a structure
comprising the success/failure, the user message, internal result,
internal result message.

The observability implementations could log the results, send counts to
Grafana, etc.  If there is no observer then no results are presented.


Alternatively the validation could accept the observability component as
an argument and pass the internal result and internal result message
directly to the observability component.

Re: [Discuss] CEP-24 Password validation and generation

[Fleming, Jackson]

I agree that the log sent back to the user is perhaps too verbose for an audit 
log, Jeff’s log format is nice in that regard, due to a clear pattern (nice for 
log parsers) with a clear distinct reason for failure that has enough details 
for an auditor to understand what happened, though it gets interesting if we 
reject for more than one reason, so we would provide the user with additional 
information compared to what we would add to the audit log.

The current solution performs several validations and reports the results of 
them all back to the user (instead of sequentially checking them and reporting 
back the first failure). Perhaps the rejection audit logs could just be 
combined into a single format with the reasons listed together, as an example:

ERROR: Password rejected due to policy violation (reuse, complexity)

As a user I’d still preference the format outlined in the cep though 
(subjective as that statement is), as it more clearly states what I would need 
to improve about the password.

Just my 2c.

Cheers,

Jackson



From: Miklosovic, Stefan 
Sent: Thursday, October 13, 2022 7:26:05 PM
To: dev@cassandra.apache.org ; Claude Warren, Jr 

Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




Hi Claude,

you said: "I don't know the govt spec. but there is a US govt security level 
where you are not allowed to inform the user why the login failed."

I do not think this is the case. Nobody is going to inform a user with existing 
role in the db why he failed to log in, when it comes to this CEP (is not it 
actually already in place? CQLSH says your username / password combo is invalid 
on login already) This CEP has nothing to do with it.

What we have in mind, I think, it is more about informing him about the details 
when the password he tries to set (upon role creation) or change (via role 
alteration), is not valid, based on the policy.

I reckon that what Jeff simply wants to see is a log if such change was 
successful or not. Lets repeat here what Jeff would like to see:

"Password changed for user X, complying with policies (reuse, complexity, 
entropy)"
"ERROR: Password rejected due to policy violation (reuse)"
"ERROR: Password rejected due to policy violation (complexity)"
"ERROR: Password rejected due to policy violation (entropy)"

This is a generalized version of what we already have in place in CEP, we have 
there information like:

Password must be 10 or more characters in length. Password must contain 2 or 
more uppercase characters. Password matches 3 of 4 character rules, but 4 are 
required.
Password matches one of 5 previous passwords.
Password must be 12 or more characters in length

Now, I have to admit that the information we provide above, in contrast of what 
Jeff mentioned, is quite verbose. It is questionable whether we should be so 
specific or whether more generalized version is enough.

Maybe two versions of the logs would be the most appropriate - ours (more 
detailed) would be returned to a user in cqlsh as a warning / error after 
unsuccessful query execution but the messages Jeff mentioned would be written 
in system logs via slf4j. So we would be detailed for a user but general for 
auditing purposes.

Do you think this makes sense to you all? I think this is want you said, more 
or less, in your middle paragraph, just formulated differently.

I agree with Jackson with the password meter e-mail. After all, if somebody 
really wants that to happen, since our solution is pluggable, people can 
implement their own password-meter-based solution if they find it necessary.

To fail a password when it is reused (or found among previous n). I am on the 
edge here. I understand what Josh is telling, that we can go just so far when 
it comes to prevent people from doing wrong things, maybe increasing the 
password history to 20 last passwords would be enough. Anyway, I plan to make 
this historical password verification optional so it might be turned on / off 
on demand.

Finally, when it comes to password dictionaries. This might be included in the 
CEP but I would keep it out for the very first implementation and it can be 
finished afterwards in some other commit. I do not find it absolutely necessary 
to do it right now.

Regards,

Stefan


From: Claude Warren, Jr via dev 
Sent: Thursday, October 13, 2022 9:44
To: dev@cassandra.apache.org
Subject: Fwd: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




I managed not to send this to the mailaing list...


I don't know the govt spec. but there is a US govt security level where
you are not allowed to inform the user why th

Re: [Discuss] CEP-24 Password validation and generation

[Claude Warren, Jr via dev]

I think we might be in violent agreement here.

The point I was trying to make is that the rules for valid passwords are
many and varied.  I have worked at places where they wanted to know the
time since the last password change, this was used to prevent the rapid
change of password to  get back to the original one (I think 5 was the
example earlier).  Anyway, the point was, identify the information
necessary from the system to fulfill the rules we think of (so far this is
the new password, a list of old passwords, and the time of the last
password change) and call a validator plugin passing it the new password,
list of passwords, date of last change, and an observer instance.

The validator implementation will verify the instance and report any issues
to the observer and return true/false and potentially a user message.

Any logging is attached to the observer, any reporting to grafana or
similar reporting is attached to the observer.

A simple implementation of the validator that performs series of
configurable tests against the password would probably be sufficient for
the validation
A simple implementation of the observer that logs the messages Jeff
suggested would probably be sufficient.

Both would allow much more complex validation and/or reporting as necessary.

On Thu, Oct 13, 2022 at 9:26 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Hi Claude,
>
> you said: "I don't know the govt spec. but there is a US govt security
> level where you are not allowed to inform the user why the login failed."
>
> I do not think this is the case. Nobody is going to inform a user with
> existing role in the db why he failed to log in, when it comes to this CEP
> (is not it actually already in place? CQLSH says your username / password
> combo is invalid on login already) This CEP has nothing to do with it.
>
> What we have in mind, I think, it is more about informing him about the
> details when the password he tries to set (upon role creation) or change
> (via role alteration), is not valid, based on the policy.
>
> I reckon that what Jeff simply wants to see is a log if such change was
> successful or not. Lets repeat here what Jeff would like to see:
>
> "Password changed for user X, complying with policies (reuse, complexity,
> entropy)"
> "ERROR: Password rejected due to policy violation (reuse)"
> "ERROR: Password rejected due to policy violation (complexity)"
> "ERROR: Password rejected due to policy violation (entropy)"
>
> This is a generalized version of what we already have in place in CEP, we
> have there information like:
>
> Password must be 10 or more characters in length. Password must contain 2
> or more uppercase characters. Password matches 3 of 4 character rules, but
> 4 are required.
> Password matches one of 5 previous passwords.
> Password must be 12 or more characters in length
>
> Now, I have to admit that the information we provide above, in contrast of
> what Jeff mentioned, is quite verbose. It is questionable whether we should
> be so specific or whether more generalized version is enough.
>
> Maybe two versions of the logs would be the most appropriate - ours (more
> detailed) would be returned to a user in cqlsh as a warning / error after
> unsuccessful query execution but the messages Jeff mentioned would be
> written in system logs via slf4j. So we would be detailed for a user but
> general for auditing purposes.
>
> Do you think this makes sense to you all? I think this is want you said,
> more or less, in your middle paragraph, just formulated differently.
>
> I agree with Jackson with the password meter e-mail. After all, if
> somebody really wants that to happen, since our solution is pluggable,
> people can implement their own password-meter-based solution if they find
> it necessary.
>
> To fail a password when it is reused (or found among previous n). I am on
> the edge here. I understand what Josh is telling, that we can go just so
> far when it comes to prevent people from doing wrong things, maybe
> increasing the password history to 20 last passwords would be enough.
> Anyway, I plan to make this historical password verification optional so it
> might be turned on / off on demand.
>
> Finally, when it comes to password dictionaries. This might be included in
> the CEP but I would keep it out for the very first implementation and it
> can be finished afterwards in some other commit. I do not find it
> absolutely necessary to do it right now.
>
> Regards,
>
> Stefan
>
> 
> From: Claude Warren, Jr via dev 
> Sent: Thursday, October 13, 2022 9:44
> To: dev@cassandra.apache.org
> Subject: Fwd: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
>
> I managed not to send this to the mailaing list...
>
>
> I don't know the govt spec. but there is a US govt s

Re: [Discuss] CEP-24 Password validation and generation

[Claude Warren, Jr via dev]

The only difference I see is that I see observability (observer) as being a
way to retrieve (or be notified about) data used within a process.  Logging
on the other hand, is a preservation of a state discovered in an observable
object.  Observability can drive logging but it can also drive aggregate
statistics in grafana, and things like that.

My reading of the CEP-3 is that it is intended to provide system-wide soft
and hard limits, it is not an observability framework.  It makes sense for
the validator to implement CEP-3 but I think that an observability
interface is required as well.

On Thu, Oct 13, 2022 at 12:36 PM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Hi Claude,
>
> all you say makes sense to me. I do not see any discrepancies. It will be
> logged as discussed already.
>
> The complexity of password validation is partly covered by the library we
> want to use (Passay). It will inform you in a very detailed manner when it
> comes to what violations of a policy there are. We are not going to invent
> a wheel here, fortunately.
>
> Terminology you used - "observer" - is Guardrail itself (CEP-3). It will
> be the one doing reporting e.g by logging and returning warnings / errors,
> if any, back to user who executed that query.
>
> The approach we took indeed can also be extended in such a way that it
> would be possible to know what was the last time a password was changed for
> some user. This is the direct consequence of us having a table of previous
> password for checking that a user is not reusing them. There is a timestamp
> column specified here (1) if you check the schema of that table closely so
> to answer "when was the password changed lastly" is rather easy to know -
> "select created from system_auth.previous passwords where role = 'stefan'
> limit 1"
>
> To your requirements:
> A simple implementation of the validator that performs series of
> configurable tests against the password would probably be sufficient for
> the validation
>
> Sure, this is configurable, by either implementing a custom validator if
> you find the default one insufficient or configuring the default one
> accordingly.
>
> "A simple implementation of the observer that logs the messages Jeff
> suggested would probably be sufficient."
>
> Yes, no problem with logging from Guardrail directly.
>
> (1)
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-24%3A+Password+validation+and+generation#CEP24:Passwordvalidationandgeneration-Validationofanewpasswordagainstpreviouspasswords
>
> Regards
>
> 
> From: Claude Warren, Jr 
> Sent: Thursday, October 13, 2022 12:50
> To: Miklosovic, Stefan
> Cc: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> I think we might be in violent agreement here.
>
> The point I was trying to make is that the rules for valid passwords are
> many and varied.  I have worked at places where they wanted to know the
> time since the last password change, this was used to prevent the rapid
> change of password to  get back to the original one (I think 5 was the
> example earlier).  Anyway, the point was, identify the information
> necessary from the system to fulfill the rules we think of (so far this is
> the new password, a list of old passwords, and the time of the last
> password change) and call a validator plugin passing it the new password,
> list of passwords, date of last change, and an observer instance.
>
> The validator implementation will verify the instance and report any
> issues to the observer and return true/false and potentially a user message.
>
> Any logging is attached to the observer, any reporting to grafana or
> similar reporting is attached to the observer.
>
> A simple implementation of the validator that performs series of
> configurable tests against the password would probably be sufficient for
> the validation
> A simple implementation of the observer that logs the messages Jeff
> suggested would probably be sufficient.
>
> Both would allow much more complex validation and/or reporting as
> necessary.
>
> On Thu, Oct 13, 2022 at 9:26 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
> Hi Claude,
>
> you said: "I don't know the govt spec. but there is a US govt security
> level where you are not allowed to inform the user why the login failed."
>
> I do not think this is the case. Nobody is going to inform a user with
> existing role in the db why he failed to log in, when it comes to this CEP
> (is not it actually already in place? CQLSH says your username / password
> combo is invalid on login already) This CEP has nothing to do with it.
>
> What we have in mind, I think, it is more about informing him about the
> details when the password he tri

Re: [Discuss] CEP-24 Password validation and generation

[Miklosovic, Stefan]

Hi Claude,

we may also integrate with Diagnostics framework Cassandra already ships. I 
would say this better suits to your requirements for observability. I am not 
sure to what degree you are familiar with Diagnostics though. To give you a 
better picture, events are fired and external observers (in the framework 
called "subscribers") would be notified about the internal accordingly. As of 
now, observers / subscribers are meant to integrate with JMX through which 
these events flow.

Do you think Diagnostics events would satisfy your needs?

Regards


From: Claude Warren, Jr via dev 
Sent: Thursday, October 13, 2022 14:43
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



The only difference I see is that I see observability (observer) as being a way 
to retrieve (or be notified about) data used within a process.  Logging on the 
other hand, is a preservation of a state discovered in an observable object.  
Observability can drive logging but it can also drive aggregate statistics in 
grafana, and things like that.

My reading of the CEP-3 is that it is intended to provide system-wide soft and 
hard limits, it is not an observability framework.  It makes sense for the 
validator to implement CEP-3 but I think that an observability interface is 
required as well.

On Thu, Oct 13, 2022 at 12:36 PM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:
Hi Claude,

all you say makes sense to me. I do not see any discrepancies. It will be 
logged as discussed already.

The complexity of password validation is partly covered by the library we want 
to use (Passay). It will inform you in a very detailed manner when it comes to 
what violations of a policy there are. We are not going to invent a wheel here, 
fortunately.

Terminology you used - "observer" - is Guardrail itself (CEP-3). It will be the 
one doing reporting e.g by logging and returning warnings / errors, if any, 
back to user who executed that query.

The approach we took indeed can also be extended in such a way that it would be 
possible to know what was the last time a password was changed for some user. 
This is the direct consequence of us having a table of previous password for 
checking that a user is not reusing them. There is a timestamp column specified 
here (1) if you check the schema of that table closely so to answer "when was 
the password changed lastly" is rather easy to know - "select created from 
system_auth.previous passwords where role = 'stefan' limit 1"

To your requirements:
A simple implementation of the validator that performs series of configurable 
tests against the password would probably be sufficient for the validation

Sure, this is configurable, by either implementing a custom validator if you 
find the default one insufficient or configuring the default one accordingly.

"A simple implementation of the observer that logs the messages Jeff suggested 
would probably be sufficient."

Yes, no problem with logging from Guardrail directly.

(1) 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-24%3A+Password+validation+and+generation#CEP24:Passwordvalidationandgeneration-Validationofanewpasswordagainstpreviouspasswords

Regards


From: Claude Warren, Jr mailto:claude.war...@aiven.io>>
Sent: Thursday, October 13, 2022 12:50
To: Miklosovic, Stefan
Cc: dev@cassandra.apache.org
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



I think we might be in violent agreement here.

The point I was trying to make is that the rules for valid passwords are many 
and varied.  I have worked at places where they wanted to know the time since 
the last password change, this was used to prevent the rapid change of password 
to  get back to the original one (I think 5 was the example earlier).  Anyway, 
the point was, identify the information necessary from the system to fulfill 
the rules we think of (so far this is the new password, a list of old 
passwords, and the time of the last password change) and call a validator 
plugin passing it the new password, list of passwords, date of last change, and 
an observer instance.

The validator implementation will verify the instance and report any issues to 
the observer and return true/false and potentially a user message.

Any logging is attached to the observer, any reporting to grafana or similar 
reporting is attached to the observer.

A simple implementation of the validator that performs series of configurable 
tests against the password would probably be sufficient for the validation
A si

Re: [Discuss] CEP-24 Password validation and generation

[Claude Warren, Jr via dev]

I am not familiar with the Diagnostics framework but it sounds like it
would satisfy the need.  Thanks for pointing it out.  I will dive into it
to get an understanding of how it works.

On Thu, Oct 13, 2022 at 1:52 PM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Hi Claude,
>
> we may also integrate with Diagnostics framework Cassandra already ships.
> I would say this better suits to your requirements for observability. I am
> not sure to what degree you are familiar with Diagnostics though. To give
> you a better picture, events are fired and external observers (in the
> framework called "subscribers") would be notified about the internal
> accordingly. As of now, observers / subscribers are meant to integrate with
> JMX through which these events flow.
>
> Do you think Diagnostics events would satisfy your needs?
>
> Regards
>
> 
> From: Claude Warren, Jr via dev 
> Sent: Thursday, October 13, 2022 14:43
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> The only difference I see is that I see observability (observer) as being
> a way to retrieve (or be notified about) data used within a process.
> Logging on the other hand, is a preservation of a state discovered in an
> observable object.  Observability can drive logging but it can also drive
> aggregate statistics in grafana, and things like that.
>
> My reading of the CEP-3 is that it is intended to provide system-wide soft
> and hard limits, it is not an observability framework.  It makes sense for
> the validator to implement CEP-3 but I think that an observability
> interface is required as well.
>
> On Thu, Oct 13, 2022 at 12:36 PM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
> Hi Claude,
>
> all you say makes sense to me. I do not see any discrepancies. It will be
> logged as discussed already.
>
> The complexity of password validation is partly covered by the library we
> want to use (Passay). It will inform you in a very detailed manner when it
> comes to what violations of a policy there are. We are not going to invent
> a wheel here, fortunately.
>
> Terminology you used - "observer" - is Guardrail itself (CEP-3). It will
> be the one doing reporting e.g by logging and returning warnings / errors,
> if any, back to user who executed that query.
>
> The approach we took indeed can also be extended in such a way that it
> would be possible to know what was the last time a password was changed for
> some user. This is the direct consequence of us having a table of previous
> password for checking that a user is not reusing them. There is a timestamp
> column specified here (1) if you check the schema of that table closely so
> to answer "when was the password changed lastly" is rather easy to know -
> "select created from system_auth.previous passwords where role = 'stefan'
> limit 1"
>
> To your requirements:
> A simple implementation of the validator that performs series of
> configurable tests against the password would probably be sufficient for
> the validation
>
> Sure, this is configurable, by either implementing a custom validator if
> you find the default one insufficient or configuring the default one
> accordingly.
>
> "A simple implementation of the observer that logs the messages Jeff
> suggested would probably be sufficient."
>
> Yes, no problem with logging from Guardrail directly.
>
> (1)
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-24%3A+Password+validation+and+generation#CEP24:Passwordvalidationandgeneration-Validationofanewpasswordagainstpreviouspasswords
>
> Regards
>
> 
> From: Claude Warren, Jr  claude.war...@aiven.io>>
> Sent: Thursday, October 13, 2022 12:50
> To: Miklosovic, Stefan
> Cc: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> I think we might be in violent agreement here.
>
> The point I was trying to make is that the rules for valid passwords are
> many and varied.  I have worked at places where they wanted to know the
> time since the last password change, this was used to prevent the rapid
> change of password to  get back to the original one (I think 5 was the
> example earlier).  Anyway, the point was, identify the information
> necessary from the system to fulfill the rules we think of (so far this is
> the new password, a list of old passwords, and the time of the last
> password change) and call a validator plugin passing it the new password,
> list of passwords, date of last change, and a

Re: [VOTE] Revising release gating criteria and CI systems

[Josh McKenzie]

With 8 +1's (and >= 3 binding), the vote passes.

I'll get the documentation updated. Thanks everyone!

On Tue, Oct 11, 2022, at 2:34 PM, Jeremiah D Jordan wrote:
> +1 nb
> 
>> On Oct 8, 2022, at 7:30 AM, Josh McKenzie  wrote:
>> 
>> DISCUSS thread: 
>> https://lists.apache.org/thread/o166v7nr9lxnzdy5511tv40rr9t6zbrw
>> 
>> Revise Release Lifecycle cwiki page 
>> (https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle):
>>  - Ensure we have parity on jobs run and coverage between circle and asf-ci
>>  - Allow usage of circleci as gatekeeper for releases. A release will 
>> require 1 green run for beta, 3 green runs consecutively for ga
>>  - No new consistent regressions on CI for asf compared to prior branches
>>  - Explicitly do not consider ci-cassandra asf flaky tests as release 
>> blockers
>> 
>> Changes to codify into documentation 
>> (https://cassandra.apache.org/_/development/how_to_commit.html):
>>  - On patch before commit, multiplex @500 all new tests, changed tests, or 
>> expected to be impacted tests ("expected to be impacted" piece pending 
>> multi-class multiplexing support).
>>  - Add support for / documentation for multi-class specification in 
>> multiplexer and document
>> 
>> Add informal project commitment during next major release lifecycle to 
>> continue working on bringing asf ci-cassandra up to where it can be formal 
>> gatekeeper for release.
>> 
>> ---
>> The vote for these revisions will run through EoD 10/12/22 to give us the 
>> weekend + 72 business hours.

Cassandra project status update 2022-10-13

[Josh McKenzie]

Late Post-ApacheCon update ftw! I'll probably give it 2.5 weeks before the next 
update so we have more time for things to settle and evolve as we run up to 4.1 
rc and ga.

First off - for all of you who couldn't make it to ApacheCon: you were missed. 
New Orleans was great (and the food there undoubtedly takes time off one's 
lifespan...). For those of you who could make it - it was great to see new 
faces and meet new folks in person while also seeing some old-timers on the 
project as well! It's incredibly energizing to have newcomers to the project 
bring their energy and fresh perspectives and experiences to the group.

During the middle of the conference the 4.1-beta vote passed - the artifacts 
are available as mentioned in Mick's previous email here: 
https://lists.apache.org/thread/nd342c3k1s3swm77gn3j0td178y7fwns.

Videos of the talks from the NA ApacheCon 2022 Cassandra Track are available 
courtesy of Jeremy Hanna's upload here: 
https://drive.google.com/drive/folders/1tOhC7G2Ezp3W-SSs2J4CiLtlZ7hutuRP. I 
hear slides should be coming out at some point but haven't heard details on 
that yet.

On the topic of conferences, the Cassandra Summit returns in 2023 - see the 
blog post on the Cassandra blog here: 
https://cassandra.apache.org/_/blog/Cassandra-Summit-Returns-in-2023.html. It 
will be held in San Jose California, March 13-14 2023 and will be hosted by the 
Linux Foundation. Call for Proposals aren't quite open yet but you can see a 
guide on starting to get information together here: 
https://events.linuxfoundation.org/cassandra-summit/program/cfp/. Also, the 
conference is looking for sponsors so if your employer would be interested in 
sponsoring or if *you* would like to be a sponsor of this event, please reach 
out to sponsorsh...@linuxfoundation.org.

Circling back to 4.1 as is tradition on these emails now, we need to first 
cover a change that's in flight: 
https://lists.apache.org/thread/26gw66ohl8zbo4ozj3yvhk19wkzl0qw0. The TL;DR: we 
just finished voting on allowing using ASF Jenkins OR circleci as release 
gating criteria for official Cassandra releases. This is largely a stopgap as 
we continue to work to improve the stability of the ASF CI infrastructure.

As a snapshot of where we are today: 
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484. We have 6 
issues blocking RC, only 1 of which is unassigned (CASSANDRA-17773 - Incorrect 
cassandra.logdir on Debian systems) which looks like more of an administrative 
oversight as Claude appears to be active on it. We do have one ticket that 
needs committer attention (CASSANDRA-17873 - Opcodes.ASM7 should be used in 
UDFByteCodeVerifier to support JDK11) that Ekaterina's working on. If any 
committers have some spare cycles your attention here would be greatly 
appreciated!


[New Contributors Getting Started]
Documentation contributions, website contributions, anything in the unassigned 
list on 4.0.x or 4.x here that you feel up to tackling: 
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2160.
 The world is your oyster. :)

We have 35 total "Starter Tickets" (i.e. a mentor has determined that the 
ticket is _probably_ a bit more bite-sized and good for getting to know the 
project) across our various releases that are unassigned right now: 
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2160&quickFilter=2162

Here's reference explaining the various types of contribution: 
https://cassandra.apache.org/_/community.html#how-to-contribute
An overview of the C* architecture: 
https://cassandra.apache.org/doc/latest/cassandra/architecture/overview.html
The getting started contributing guide: 
https://cassandra.apache.org/_/development/index.html
We hang out in #cassandra-dev on https://the-asf.slack.com and there's a 
@cassandra_mentors alias you can use to reach a bunch of us that have 
volunteered to help newcomers get situated. If you need an invite to the slack 
channel feel free to reply to just me on this email and I'll get you set up.


[Dev list Digest]
https://lists.apache.org/list?dev@cassandra.apache.org:lte=14d:

Pretty busy couple of weeks. There's an ongoing discussion about password 
validation and generation and CEP-24 that is covering some really solid ground 
on just how far is appropriate to go with the feature, what we'd like as 
operators, what we think is industry standard in our field, etc. You can chime 
in on the thread: 
https://lists.apache.org/thread/454tmo2r9238rj69j7h3xv43crygv31m

We have a new episode of the Apache Cassandra Corner on staging that'll go live 
Friday night - if you'd like, feel free to preview it and provide Aaron with 
your feedback: https://lists.apache.org/thread/7prkk4dndfvf8oxsb17o74z61wknrn45

Derek Chen-Becker (ApacheCon presenter extraordinaire!) is looking for 
reviewers on a circleci config and doc fix - we have PR's for that linked in 
his email: https://lists.apache.org/thread/lt0tplx19k6xvbl

Re: Cassandra project status update 2022-10-13

[Derek Chen-Becker]

Hi Josh,

I do have a ticket for the CircleCI addition:
https://issues.apache.org/jira/browse/CASSANDRA-17950. It's a subtask of
https://issues.apache.org/jira/browse/CASSANDRA-17930, which I'm planning
on doing more work on once I get confirmation that I'm not doing something
wrong with CircleCI :)

I put the JIRA ID in the commit message but I guess I forgot to mention it
in the request for reviewer :(

For the doc PR Mick just said to submit the PR first since it's a small
change, but I'm happy to open a JIRA ticket for it if that's a more
appropriate path.

Cheers,

Derek

On Thu, Oct 13, 2022 at 11:17 AM Josh McKenzie  wrote:

> Late Post-ApacheCon update ftw! I'll probably give it 2.5 weeks before the
> next update so we have more time for things to settle and evolve as we run
> up to 4.1 rc and ga.
>
> First off - for all of you who couldn't make it to ApacheCon: you were
> missed. New Orleans was great (and the food there undoubtedly takes time
> off one's lifespan...). For those of you who could make it - it was great
> to see new faces and meet new folks in person while also seeing some
> old-timers on the project as well! It's incredibly energizing to have
> newcomers to the project bring their energy and fresh perspectives and
> experiences to the group.
>
> During the middle of the conference the 4.1-beta vote passed - the
> artifacts are available as mentioned in Mick's previous email here:
> https://lists.apache.org/thread/nd342c3k1s3swm77gn3j0td178y7fwns.
>
> Videos of the talks from the NA ApacheCon 2022 Cassandra Track are
> available courtesy of Jeremy Hanna's upload here:
> https://drive.google.com/drive/folders/1tOhC7G2Ezp3W-SSs2J4CiLtlZ7hutuRP.
> I hear slides should be coming out at some point but haven't heard details
> on that yet.
>
> On the topic of conferences, the Cassandra Summit returns in 2023 - see
> the blog post on the Cassandra blog here:
> https://cassandra.apache.org/_/blog/Cassandra-Summit-Returns-in-2023.html.
> It will be held in San Jose California, March 13-14 2023 and will be hosted
> by the Linux Foundation. Call for Proposals aren't quite open yet but you
> can see a guide on starting to get information together here:
> https://events.linuxfoundation.org/cassandra-summit/program/cfp/. Also,
> the conference is looking for sponsors so if your employer would be
> interested in sponsoring or if *you* would like to be a sponsor of this
> event, please reach out to sponsorsh...@linuxfoundation.org.
>
> Circling back to 4.1 as is tradition on these emails now, we need to first
> cover a change that's in flight:
> https://lists.apache.org/thread/26gw66ohl8zbo4ozj3yvhk19wkzl0qw0. The
> TL;DR: we just finished voting on allowing using ASF Jenkins OR circleci as
> release gating criteria for official Cassandra releases. This is largely a
> stopgap as we continue to work to improve the stability of the ASF CI
> infrastructure.
>
> As a snapshot of where we are today:
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484. We
> have 6 issues blocking RC, only 1 of which is unassigned (CASSANDRA-17773 -
> Incorrect cassandra.logdir on Debian systems) which looks like more of an
> administrative oversight as Claude appears to be active on it. We do have
> one ticket that needs committer attention (CASSANDRA-17873 - Opcodes.ASM7
> should be used in UDFByteCodeVerifier to support JDK11) that Ekaterina's
> working on. If any committers have some spare cycles your attention here
> would be greatly appreciated!
>
>
> [New Contributors Getting Started]
> Documentation contributions, website contributions, anything in the
> unassigned list on 4.0.x or 4.x here that you feel up to tackling:
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2160.
> The world is your oyster. :)
>
> We have 35 total "Starter Tickets" (i.e. a mentor has determined that the
> ticket is _probably_ a bit more bite-sized and good for getting to know the
> project) across our various releases that are unassigned right now:
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2160&quickFilter=2162
>
> Here's reference explaining the various types of contribution:
> https://cassandra.apache.org/_/community.html#how-to-contribute
> An overview of the C* architecture:
> https://cassandra.apache.org/doc/latest/cassandra/architecture/overview.html
> The getting started contributing guide:
> https://cassandra.apache.org/_/development/index.html
> We hang out in #cassandra-dev on https://the-asf.slack.com and there's a
> @cassandra_mentors alias you can use to reach a bunch of us that have
> volunteered to help newcomers get situated. If you need an invite to the
> slack channel feel free to reply to just me on this email and I'll get you
> set up.
>
>
> [Dev list Digest]
> https://lists.apache.org/list?dev@cassandra.apache.org:lte=14d:
>
> Pretty busy couple of weeks. There's an ongoing discussion about password
> validation and generation 

Re: Cassandra project status update 2022-10-13

[Josh McKenzie]

Awesome - was missing the link to CASSANDRA-17930. That's a good home to link 
these efforts to. Thanks!

On Thu, Oct 13, 2022, at 1:21 PM, Derek Chen-Becker wrote:
> Hi Josh,
> 
> I do have a ticket for the CircleCI addition: 
> https://issues.apache.org/jira/browse/CASSANDRA-17950. It's a subtask of 
> https://issues.apache.org/jira/browse/CASSANDRA-17930, which I'm planning on 
> doing more work on once I get confirmation that I'm not doing something wrong 
> with CircleCI :)
> 
> I put the JIRA ID in the commit message but I guess I forgot to mention it in 
> the request for reviewer :( 
> 
> For the doc PR Mick just said to submit the PR first since it's a small 
> change, but I'm happy to open a JIRA ticket for it if that's a more 
> appropriate path.
> 
> Cheers,
> 
> Derek
> 
> On Thu, Oct 13, 2022 at 11:17 AM Josh McKenzie  wrote:
>> __
>> Late Post-ApacheCon update ftw! I'll probably give it 2.5 weeks before the 
>> next update so we have more time for things to settle and evolve as we run 
>> up to 4.1 rc and ga.
>> 
>> First off - for all of you who couldn't make it to ApacheCon: you were 
>> missed. New Orleans was great (and the food there undoubtedly takes time off 
>> one's lifespan...). For those of you who could make it - it was great to see 
>> new faces and meet new folks in person while also seeing some old-timers on 
>> the project as well! It's incredibly energizing to have newcomers to the 
>> project bring their energy and fresh perspectives and experiences to the 
>> group.
>> 
>> During the middle of the conference the 4.1-beta vote passed - the artifacts 
>> are available as mentioned in Mick's previous email here: 
>> https://lists.apache.org/thread/nd342c3k1s3swm77gn3j0td178y7fwns.
>> 
>> Videos of the talks from the NA ApacheCon 2022 Cassandra Track are available 
>> courtesy of Jeremy Hanna's upload here: 
>> https://drive.google.com/drive/folders/1tOhC7G2Ezp3W-SSs2J4CiLtlZ7hutuRP. I 
>> hear slides should be coming out at some point but haven't heard details on 
>> that yet.
>> 
>> On the topic of conferences, the Cassandra Summit returns in 2023 - see the 
>> blog post on the Cassandra blog here: 
>> https://cassandra.apache.org/_/blog/Cassandra-Summit-Returns-in-2023.html. 
>> It will be held in San Jose California, March 13-14 2023 and will be hosted 
>> by the Linux Foundation. Call for Proposals aren't quite open yet but you 
>> can see a guide on starting to get information together here: 
>> https://events.linuxfoundation.org/cassandra-summit/program/cfp/. Also, the 
>> conference is looking for sponsors so if your employer would be interested 
>> in sponsoring or if *you* would like to be a sponsor of this event, please 
>> reach out to sponsorsh...@linuxfoundation.org.
>> 
>> Circling back to 4.1 as is tradition on these emails now, we need to first 
>> cover a change that's in flight: 
>> https://lists.apache.org/thread/26gw66ohl8zbo4ozj3yvhk19wkzl0qw0. The TL;DR: 
>> we just finished voting on allowing using ASF Jenkins OR circleci as release 
>> gating criteria for official Cassandra releases. This is largely a stopgap 
>> as we continue to work to improve the stability of the ASF CI infrastructure.
>> 
>> As a snapshot of where we are today: 
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484. We have 
>> 6 issues blocking RC, only 1 of which is unassigned (CASSANDRA-17773 - 
>> Incorrect cassandra.logdir on Debian systems) which looks like more of an 
>> administrative oversight as Claude appears to be active on it. We do have 
>> one ticket that needs committer attention (CASSANDRA-17873 - Opcodes.ASM7 
>> should be used in UDFByteCodeVerifier to support JDK11) that Ekaterina's 
>> working on. If any committers have some spare cycles your attention here 
>> would be greatly appreciated!
>> 
>> 
>> [New Contributors Getting Started]
>> Documentation contributions, website contributions, anything in the 
>> unassigned list on 4.0.x or 4.x here that you feel up to tackling: 
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2160.
>>  The world is your oyster. :)
>> 
>> We have 35 total "Starter Tickets" (i.e. a mentor has determined that the 
>> ticket is _probably_ a bit more bite-sized and good for getting to know the 
>> project) across our various releases that are unassigned right now: 
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2160&quickFilter=2162
>> 
>> Here's reference explaining the various types of contribution: 
>> https://cassandra.apache.org/_/community.html#how-to-contribute
>> An overview of the C* architecture: 
>> https://cassandra.apache.org/doc/latest/cassandra/architecture/overview.html
>> The getting started contributing guide: 
>> https://cassandra.apache.org/_/development/index.html
>> We hang out in #cassandra-dev on https://the-asf.slack.com and there's a 
>> @cassandra_mentors alias you can use to reach a bunch of us that have 
>> volunteered