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.

Sign up for GitHub

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

Jump to bottom

Improve detection and warning of process warnings #59646

Closed
watson opened this issue Mar 9, 2020 · 1 comment · Fixed by #59651
Closed

Improve detection and warning of process warnings #59646

watson opened this issue Mar 9, 2020 · 1 comment · Fixed by #59651
Assignees
@watson
Labels
Feature:Hardening Harding of Kibana from a security perspective Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@watson
Copy link
Contributor

watson commented Mar 9, 2020 •
edited
Loading

We landed stricter detection of deprecation warnings in #51431. This was primarily achieved by using the --throw-deprecation flag. This, however, will be caught if the offending code is surrounded by a try-catch, which means any deprecated API used synchronously inside of a promise or in an async-await context will be caught and not exit the process, which in turn most likely means that it will go unnoticed.

We should improve this by crashing the process even in these cases (by utilizing process.on('warning')).
@watson watson added Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Feature:Hardening Harding of Kibana from a security perspective labels Mar 9, 2020
@watson watson self-assigned this Mar 9, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security (Team:Security)

@watson watson mentioned this issue Mar 9, 2020
Merged
watson added a commit that referenced this issue Mar 12, 2020
@watson
Ensure process exits if a process warning is emitted (#59651)
ec78348 
Crash Kibana in dev/CI if a process warning is detected. This does not
influence how Kibana behaves in production when run via `./bin/kibana`
as there the `--no-warnings` flag is used. We will detect this flag and
as a result, disable this behavior.

Previously we used the flags `--trace-warnings --throw-deprecation` when
you started Kibana via `yarn start` and we used `--throw-deprecation` in
CI. This meant that we would only crash on deprecation warnings and log
a stack trace for all other types of warnings.

There were a couple of drawbacks to this approach:

1. If the deprecated API was called in a place enclosed in a try-catch
   (or inside of a Promise or an async/await context), the throw would
   be caught and the program would not crash.

2. If you ran `./scripts/kibana` directly instead of running `yarn
   start`, you would not get these flags automatically.

3. If you ran any of our tests locally you would not get the standard CI
   flags. This meant something that might seem to pass locally would not
   pass in CI.

This commit changes this behavior by ensuring:

- That we always crash - no matter if the offending code is surrounded
  by a try-catch (etc).

- That you always get the same behavior whether you run `yarn start` or
  `./scripts/kibana`.

- That you always get the same behavior in CI or if you run individual
  tests locally.

Furthermore, we now crash for all types of warnings - not only
deprecation warnings (except `MaxListenersExceededWarning`).

Closes #59646
watson added a commit to watson/kibana that referenced this issue Mar 12, 2020
@watson
Ensure process exits if a process warning is emitted (elastic#59651)
c2078ea 
Crash Kibana in dev/CI if a process warning is detected. This does not
influence how Kibana behaves in production when run via `./bin/kibana`
as there the `--no-warnings` flag is used. We will detect this flag and
as a result, disable this behavior.

Previously we used the flags `--trace-warnings --throw-deprecation` when
you started Kibana via `yarn start` and we used `--throw-deprecation` in
CI. This meant that we would only crash on deprecation warnings and log
a stack trace for all other types of warnings.

There were a couple of drawbacks to this approach:

1. If the deprecated API was called in a place enclosed in a try-catch
   (or inside of a Promise or an async/await context), the throw would
   be caught and the program would not crash.

2. If you ran `./scripts/kibana` directly instead of running `yarn
   start`, you would not get these flags automatically.

3. If you ran any of our tests locally you would not get the standard CI
   flags. This meant something that might seem to pass locally would not
   pass in CI.

This commit changes this behavior by ensuring:

- That we always crash - no matter if the offending code is surrounded
  by a try-catch (etc).

- That you always get the same behavior whether you run `yarn start` or
  `./scripts/kibana`.

- That you always get the same behavior in CI or if you run individual
  tests locally.

Furthermore, we now crash for all types of warnings - not only
deprecation warnings (except `MaxListenersExceededWarning`).

Closes elastic#59646
watson added a commit that referenced this issue Mar 12, 2020
@watson
Ensure process exits if a process warning is emitted (#59651) (#59980)
9fb405f 
Crash Kibana in dev/CI if a process warning is detected. This does not
influence how Kibana behaves in production when run via `./bin/kibana`
as there the `--no-warnings` flag is used. We will detect this flag and
as a result, disable this behavior.

Previously we used the flags `--trace-warnings --throw-deprecation` when
you started Kibana via `yarn start` and we used `--throw-deprecation` in
CI. This meant that we would only crash on deprecation warnings and log
a stack trace for all other types of warnings.

There were a couple of drawbacks to this approach:

1. If the deprecated API was called in a place enclosed in a try-catch
   (or inside of a Promise or an async/await context), the throw would
   be caught and the program would not crash.

2. If you ran `./scripts/kibana` directly instead of running `yarn
   start`, you would not get these flags automatically.

3. If you ran any of our tests locally you would not get the standard CI
   flags. This meant something that might seem to pass locally would not
   pass in CI.

This commit changes this behavior by ensuring:

- That we always crash - no matter if the offending code is surrounded
  by a try-catch (etc).

- That you always get the same behavior whether you run `yarn start` or
  `./scripts/kibana`.

- That you always get the same behavior in CI or if you run individual
  tests locally.

Furthermore, we now crash for all types of warnings - not only
deprecation warnings (except `MaxListenersExceededWarning`).

Closes #59646
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@watson watson

Labels
Feature:Hardening Harding of Kibana from a security perspective Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Ensure process exits if a process warning is emitted watson/kibana
2 participants
@watson @elasticmachine