Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Version.V_6_x_x constants use in security #41185

Merged
merged 5 commits into from
Apr 26, 2019

Conversation

tvernum
Copy link
Contributor

@tvernum tvernum commented Apr 15, 2019

This removes some use of the v6 constants in various parts of
security.
Mostly this is BWC code, which is no longer needed as ES8 will
not need to maintain compatibility with ES6.

Relates: #41164

This removes some use of the v6 constants in various parts of
security.
Mostly this is BWC testing code, which is no longer needed as ES8 will
not need to maintain compatibility with ES6.

Relates: elastic#41164
@tvernum tvernum added >non-issue :Security/Security Security issues without another label v8.0.0 labels Apr 15, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@tvernum
Copy link
Contributor Author

tvernum commented Apr 15, 2019

I didn't touch anything to do with Tokens, given the current work being done there.

There's also a separate change needed for builtin users that were defined in v6.x, which can be handled separately.

Copy link
Contributor

@albertzaharovits albertzaharovits left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@albertzaharovits
Copy link
Contributor

Thought the failures pointed to by elasticsearch-ci/1 in the hlrc project are legit:

REPRODUCE WITH: ./gradlew :client:rest-high-level:test --tests "org.elasticsearch.client.security.hlrc.HasPrivilegesResponseTests.testSerializationV63" -Dtests.seed=1B98AD2BA6D61B7B -Dtests.security.manager=true -Dtests.locale=luy-KE -Dtests.timezone=PST -Dcompiler.java=12 -Druntime.java=11
REPRODUCE WITH: ./gradlew :client:rest-high-level:test --tests "org.elasticsearch.client.security.hlrc.HasPrivilegesResponseTests.testSerializationV64OrV65" -Dtests.seed=1B98AD2BA6D61B7B -Dtests.security.manager=true -Dtests.locale=luy-KE -Dtests.timezone=PST -Dcompiler.java=12 -Druntime.java=11

Looks like some pruning is required there as well.

Copy link
Contributor

@bizybot bizybot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Thank you.

@tvernum tvernum merged commit 380172b into elastic:master Apr 26, 2019
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Apr 26, 2019
…s-in-all-the-places

* elastic/master: (70 commits)
  Remove experimental label froms script_score query (elastic#41572)
  [Ml-Dataframe] Update URLs in Data frame client java doc (elastic#41539)
  Reenable bwc Tests in master (elastic#41540)
  Fix search_as_you_type's sub-fields to pick their names from the full path of the root field (elastic#41541)
  Remove search analyzers from DocumentFieldMappers (elastic#41484)
  Update community client and integration docs (elastic#41513)
  Remove Version.V_6_x_x constants use in security (elastic#41185)
  Mute testDriverConfigurationWithSSLInURL
  Remove dedicated SSL network write buffer (elastic#41283)
  Disable max score optimization for queries with unbounded max scores (elastic#41361)
  [DOCS] Explicitly set section IDs for Asciidoctor migration (elastic#41547)
  [ML] add multi node integ tests for data frames (elastic#41508)
  [Docs] Fix common word repetitions (elastic#39703)
  [DOCS] Note TESTRESPONSE can't be used immediately after TESTSETUP (elastic#41542)
  Update configuring-ldap-realm.asciidoc (elastic#40427)
  Fixed very small typo in date (elastic#41398)
  Refactor GeoHashUtils (elastic#40869)
  Make 0 as invalid value for `min_children` in `has_child` query (elastic#41347)
  field_caps: adapt bwc version after backport (elastic#41427)
  Remove Exists Check from S3 Repository Deletes (elastic#40931)
  ...
akhil10x5 pushed a commit to akhil10x5/elasticsearch that referenced this pull request May 2, 2019
This removes some use of the v6 constants in various parts of
security.
Mostly this is BWC testing code, which is no longer needed as ES8 will
not need to maintain compatibility with ES6.

Relates: elastic#41164
gurkankaymak pushed a commit to gurkankaymak/elasticsearch that referenced this pull request May 27, 2019
This removes some use of the v6 constants in various parts of
security.
Mostly this is BWC testing code, which is no longer needed as ES8 will
not need to maintain compatibility with ES6.

Relates: elastic#41164
ywangd added a commit to ywangd/elasticsearch that referenced this pull request Dec 8, 2022
Officially Elasticsearch is compatible with last major at data level.
Therefore v8 is not compatible with v6. However we don't have a guided
migration path for stored authentication headers, e.g. upgrade assistant
does not do anything for them. Therefore it is more helpful and user
friendly for v8 to support v6 stored authentication headers.

This PR adds back the version conditional logic removed in elastic#41185 along
with tests.
droberts195 added a commit to droberts195/elasticsearch that referenced this pull request Dec 12, 2022
Due to elastic#41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to elastic#87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.
elasticsearchmachine pushed a commit that referenced this pull request Dec 12, 2022
Officially Elasticsearch is compatible with last major at data level.
Therefore v8 is not compatible with v6. However we don't have a guided
migration path for stored authentication headers, e.g. upgrade assistant
does not do anything for them. Therefore it is more helpful and user
friendly for v8 to support v6 stored authentication headers.

This PR adds back the version conditional logic removed in #41185 along
with tests.
ywangd added a commit to ywangd/elasticsearch that referenced this pull request Dec 12, 2022
…2221)

Officially Elasticsearch is compatible with last major at data level.
Therefore v8 is not compatible with v6. However we don't have a guided
migration path for stored authentication headers, e.g. upgrade assistant
does not do anything for them. Therefore it is more helpful and user
friendly for v8 to support v6 stored authentication headers.

This PR adds back the version conditional logic removed in elastic#41185 along
with tests.
elasticsearchmachine pushed a commit that referenced this pull request Dec 12, 2022
…92295)

Officially Elasticsearch is compatible with last major at data level.
Therefore v8 is not compatible with v6. However we don't have a guided
migration path for stored authentication headers, e.g. upgrade assistant
does not do anything for them. Therefore it is more helpful and user
friendly for v8 to support v6 stored authentication headers.

This PR adds back the version conditional logic removed in #41185 along
with tests.
droberts195 added a commit that referenced this pull request Dec 13, 2022
…2274)

Due to #41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to #87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by #92168 and fixed by #92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.
droberts195 added a commit to droberts195/elasticsearch that referenced this pull request Dec 13, 2022
…astic#92274)

Due to elastic#41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to elastic#87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.
elasticsearchmachine pushed a commit that referenced this pull request Dec 13, 2022
…2274) (#92318)

Due to #41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to #87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by #92168 and fixed by #92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.
droberts195 added a commit to droberts195/elasticsearch that referenced this pull request Dec 13, 2022
Due to elastic#41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to elastic#87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

Backport of elastic#92274
droberts195 added a commit to droberts195/elasticsearch that referenced this pull request Dec 13, 2022
Due to elastic#41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to elastic#87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

Backport of elastic#92274
elasticsearchmachine pushed a commit that referenced this pull request Dec 13, 2022
…em (#92323)

Due to #41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to #87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by #92168 and fixed by #92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

Backport of #92274
droberts195 added a commit that referenced this pull request Dec 13, 2022
…em (#92324)

Due to #41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to #87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by #92168 and fixed by #92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

Backport of #92274
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>non-issue :Security/Security Security issues without another label v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants