Git Product home page Git Product logo

netflix-skunkworks / stethoscope-app Goto Github PK

View Code? Open in Web Editor NEW
456.0 135.0 54.0 53.48 MB

A desktop application that checks security-related settings and makes recommendations for improvements without requiring central device management or automated reporting.

License: Apache License 2.0

HTML 2.76% NSIS 0.23% CSS 9.63% JavaScript 82.54% Shell 4.42% C# 0.39% Procfile 0.03%
security usable-security endpoint-security javascript electron macos-security windows-security linux-security hacktoberfest

stethoscope-app's Introduction

DEPRECATED

Thank you for your interest in Stethoscope! This iteration of Stethoscope has been deprecated and is being left up for posterity. We pivoted away from this project in 2019 and developed a browser extension and native helper application that improve the overall usability and effectiveness of endpoint security and device discovery.

Thank you to all our internal and external contributors, we appreciate your work toward making security more usable!


Build status Apache 2.0 NetflixOSS Lifecycle Snyk Dependencies Current Version Current Release

The Stethoscope app is a desktop application created by Netflix that checks security-related settings and makes recommendations for improving the configuration of your computer, without requiring central device management or automated reporting.

Stethoscope app screenshot

Opening the app will run a quick check of your device configuration and present recommendations and instructions.

It does not automatically report device status to a central server, but can be configured to allow requests from particular web pages. This approach enables data collection and device-to-user mapping when people access certain web applications or go through integrated web authentication flows.

The Stethoscope app is built using Electron, kmd, and GraphQL.

For examples of data reporting via a web application (in Chrome or Firefox), see the stethoscope-examples repo.

If you're looking for the Stethoscope web application, that can be found at Netflix/stethoscope.

Quick Start

Run the app and GraphQL server (currently requires port 37370)

yarn install
yarn start

About the Stethoscope app

Philosophy

The Stethoscope app is a user-respecting, decentralized approach to promoting good security configurations for desktop and laptop computers.

Read only

The Stethoscope app reports on your device status and makes recommendations, but does not change any settings proactively. This makes it fundamentally safer than systems management tools that can automatically change settings or install files.

User visible

Instead of an invisible background agent, the Stethoscope app runs as a regular application, with a user interface. This gives us a way to provide instructions, and we believe that a visible application communicates a certain level of user trust and control–we’re not trying to trick anybody into running anything.

Low overhead

The Stethoscope app does not continuously monitor–it scans and reports when the app is run, or when the app is reporting via an allowed website. As a result, the application has essentially no impact on device performance.

Report when needed

Device information is never reported straight from the app to a central server. It is only collected when required by a requesting website. This approach is more privacy respecting, and is more appropriate for situations where people are using devices that aren’t issued by a corporate IT department.

Technical approach

The Stethoscope app uses kmd to to execute and parse output from bash, powershell, and bundled executables (e.g. bitlocker-status.exe) to obtain system information. Rather than running scheduled queries in the background, graphql queries trigger execution of relevant scripts.

The Electron app runs an express web server that is only accessible locally (127.0.0.1), not over the network. This web server presents a GraphQL api for device information and policy status.

Even though the server runs over HTTP, most browsers carve out an exception for mixed content from 127.0.0.1. Webkit (Safari) does not currently conform to the spec; however, there is an ongoing ticket requesting they address this.

Local device checks and instructions

The app is built with a default policy, which specifies recommended OS versions and security settings: disk encryption, screensaver password, no remote login, etc. When you open the app, it will run the bash/powershell device queries, evaluate the results against the policy, and show instructions for any recommended actions.

This will work as a standalone checklist, without needing to report any data to a central server. In fact, it doesn’t even require internet connectivity.

You can update the policy guidelines (OS versions, required settings, etc.) in src/practices/policy.yaml, and change the instructions in src/practices/instructions.en.yaml.

Queries from a website provide their own policy and policy variables.

Learn more about policies.

Data collection and reporting

Rather than automatically reporting to a central server, data from the Stethoscope app is requested in client side JavaScript from allowed web pages. The allowed sites are listed in practices/config.yaml, and is enforced via a CORS policy. This local web server is only accessible on the loopback interface, so other devices on the network cannot reach it.

This method works in Chrome and Firefox, which properly support allowing requests to http://127.0.0.1 even from https pages. If you need this reporting mechanism to work in unsupported browsers, browser extensions can broker the communication.

The Stethoscope app can also be launched from a web page using the stethoscope:// protocol handler.

GraphQL query and response examples

Local development

yarn start will run the Electron app, the GraphQL server, and a webpack dev server with the React UI, which allows for live reloading and a faster development cycle.

This requires port 12000 for webpack dev server, and port 37370 for the GraphQL server.

Building and deploying

The Stethoscope app uses electron-builder for packaging, code signing, and autoupdating, so you can follow their configuration instructions.

Examples for building, signing, and publishing builds

Contributing

We’re specifically looking for comments and ideas regarding:

  • Use cases for your organization
  • Integration opportunities
  • Reporting formats and/or standards

Contact

You can reach the Stethoscope development team at [email protected] and via our Gitter.

stethoscope-app's People

Contributors

0xtf avatar abhaga avatar andrewmwhite avatar aspyker avatar cfarvidson avatar dependabot[bot] avatar erichs avatar esirkova avatar homebysix avatar jkriss avatar mstorus avatar mutewinter avatar nathancharles avatar nicolegrinstead avatar oolongbrothers avatar rmcvey avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

stethoscope-app's Issues

v2.1.0 fails to start on Linux due to wrong osquery reference

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    After building successfully v.2.10 of the app, when trying to start it on Linux (Kubuntu 18.04), the application doesn't start

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  1. Build the Linux binary with: yarn build:linux
  2. Then start the AppImage
  3. It would crash with the following exception:

error: Unable to kill process error: exiting on uncaught exception error: connect ENOENT /tmp/osquery.em error: exiting on uncaught exception

  • What is the expected behavior?
    The application should successfully start and do an initial scan of the system

  • What is the motivation / use case for changing the behavior?

  • Please tell us about your environment:

    • Stethoscope Version: v.2.1.0
    • Platform:
      • Mac
      • Windows
      • Linux
    • Browser: N/A
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Suggestion to fix - update the package.json to reference the correct osquery binary for Linux distribution

Log origin errors only when failing

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

Stethoscope can report valid CORS hosts as invalid in logs, even when requests make it through.

  • What is the expected behavior?

Only logged when bad request is made

  • What is the motivation / use case for changing the behavior?

Valid logging to help debug issues

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows

Long running app process eventually fails

  • I'm submitting a ...
    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.

This is a bit of a bug report and feature request. We need to move to using a thrift socket rather than shelling out to osquery, shelling out has been causing issues when users leave the app open for long periods of time.

  • What is the current behavior?

Empty responses from the server, seems to be an inability to create any more child processes.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Leave the app open for 5+ days

  • What is the expected behavior?

App should work regardless of how much time it has been running.

  • What is the motivation / use case for changing the behavior?

Mainly performance

  • Please tell us about your environment:

    • Stethoscope Version: all releases up to 1.1.9
    • Platform:
      • Mac
      • Windows
    • Browser: N/A

App requires 'localhost' resolution to function

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

If localhost and/or ::1 is overridden in /etc/hosts the app does not function.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  • Comment out localhost references in your /etc/hosts:
# 127.0.0.1 localhost
# ::1 localhost
  • launch the application
  • observe the app immediately errors out
  • What is the expected behavior?

App works.

  • Please tell us about your environment:

    • Stethoscope Version: 2.0.5
    • Platform:
      • Mac
      • Windows

Linux: Clicking red X in electron app quits Stethoscope instead of minimizing to tray

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    Clicking red X in 4.0.0 / 4.0.1 electron app quits Stethoscope instead of minimizing to tray

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
      • Linux

Regressions in Windows and Linux platforms since 3.0.5

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    The following fields currently (v3.1.3) return null/Unavailable, despite being available in prior versions (v3.0.5 is what I tested against):

Linux:

  • DeviceId

Windows:

  • DeviceId

  • HardwareSerial

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  • What is the expected behavior?

  • What is the motivation / use case for changing the behavior?
    We should provide data if/when available.

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
      • Linux
    • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

I believe this to be caused by a reworking of kmd property hierarchies. I'll take a stab at a fix in a separate PR.

Auto-update appears to hang for Linux AppImages when upgrading from 3.0.4 to 3.0.5

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    Stethoscope is running as currently-logged-in user, launched from Activities menu or via auto-start on boot. When prompted to upgrade to latest version, Electron correctly downloads the necessary files to ~/.config/Stethoscope/__update__. Then the app flashes a window saying "Updates downloaded, Stethoscope will quit and relaunch."

The app does not quit, however.

Manually quitting the app will allow the update to continue in the background, and the downloaded (in this case 3.0.5 version) app will be moved into its final spot, replacing the previous versions' AppImage file.

Launching Stethoscope manually from the Activities menu at this point starts up 3.0.5 just fine.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

See above.

  • What is the expected behavior?

The user-owned process started from the 3.0.4 AppImage should close, and automatically launch the 3.0.5 process.

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
      • Linux (Ubuntu 18.04)

Improve error handling/messaging

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

Pretty much the only error users ever see is "Request timeout", which isn't helpful to anyone. We need to do a better job of surfacing actual errors to end users, even if only to help debug issues that pop up.

  • What is the expected behavior?

tldr; errors aren't swallowed by app.

  • What is the motivation / use case for changing the behavior?

Visibility for the user when things go wrong, ultimately this data will be helpful when we need to resolve issue.

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
      • Linux

Templated os queries

  • I'm submitting a ...

    • bug report
    • feature request
  • Do you want to request a feature ?

Thanks so much for creating this project. It will be really helpful for us (as a non profit concerned about operational security). The ability to query the app from a web site is very cool...

Can I suggest an extension to your "templated_instructions" branch? What about adding templated os queries? So the os query for pass / fail for each branch is included in the instructions.yaml for each platform. This will allow you to add new checks very quickly without writing new code for each check, and it will make the tool much more flexible for organisations requiring a different suite of checks.

Add Stethoscope to Homebrew

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

Stethoscope is not available via the homebrew macOS package manager

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  • What is the expected behavior?

To be able to run brew cask install stethoscope to install Stethoscope.

  • What is the motivation / use case for changing the behavior?

To make it easy to automate deployment of across fleets of macOS machines in a standard fashion.

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
    • Browser: [N/A]
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Either a cask could be added to the official homebrew: https://github.com/Homebrew/homebrew-cask/blob/master/doc/development/adding_a_cask.md

Or a homebrew 'tap' could be created: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap

Improve "new version available" dialog

I'm submitting a ...

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note at the top of this template.

What is the current behavior?

image

This dialog comes up when an update is available.

What is the expected behavior?

  • The window should have a title, something like "Stethoscope update available"
  • "do you want update now" should be "do you want to update now" (Maybe even better: "A new version is available, would you like to download and update?"
  • The "Yes" button should be styled as a primary action

Additionally, it might be clearer to have more action oriented button labels, like "Update now" and "Not now". (Relatedly: what happens if people decline to update? Does this prompt come up again later, or does it stay quiet until the next version comes out?)

What is the motivation / use case for changing the behavior?

Fixing the typo, plus generally improving clarity of message and actions.

Please tell us about your environment:

  • Stethoscope Version: 3.1.0
  • Platform:
    • Mac
    • Windows
  • Browser: [n/a]

DISCUSSION: On Darwin, leverage/convert/borrow logic for static macmodels.js from https://github.com/MagerValp/MacModelShelf

  • I'm submitting a ...

    • [√] feature request... kinda?
      (I caught y'all on the way out the door at querycon, before I knock y'all over the head with feature requests to run arbitrary mgmt tool health checks to display in stethoscope...)
  • What is the current behavior?
    https://github.com/Netflix-Skunkworks/stethoscope-app/blob/21fd92d4cff9625507ea567e8d6cab44624e15d8/sources/macmodels.js stores the (I'm assuming manually updated?) static file of models instead of leveraging a db or doing a web call to lookup the model in case of a 'cache miss'

  • What is the expected behavior?
    I'm not saying/suggesting fire up python for this, but leverage the already-done work gathered in that repo to maybe add that db as a backend instead of the flat file, and as a fallback query Apple's long-standing... semi-official 'API'
    https://github.com/MagerValp/MacModelShelf/blob/master/macmodelshelf.py#L42
    I've hit Apple's site from that modified code hundreds of times over the past year with internal tooling...

  • What is the motivation / use case for changing the behavior?
    While your data structure in the flat file is probably fine from a performance standpoint, being able to do a lookup if you get a miss from the static cache may be desirable. And more folks aware of the work Per's done/contributing to it would be cool!

  • Please tell us about your environment:

    • Platforms:

      • Predominately Mac
      • 4-digit workstation Linux
      • Rounding error Windows
    • Stethoscope (App) Version: initial release June 2018

Provide signed builds?

  • I'm submitting a ...
    • bug report
    • feature request
    • support request

It would be great if signed builds for Windows and macOS could be provided. Building locally is easy, but getting Mac and Windows certificates is a hurdle for teams who aren't developing on those platforms. Since I assume the maintainers already have certificates available, it'd be appreciated if they could use them to publish builds.

  • What is the motivation / use case for changing the behavior?

Not only will this give a good way for teams to demo Stethoscope without code signing warnings, teams who don't need to change the default configs can use the builds directly.

Namespace env variable to something other than `NODE_ENV`

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

Stethoscope makes a number of decisions based on the value of NODE_ENV. If a user has this env var set to something other than production the app may not work correctly.

  • What is the expected behavior?

App works regardless of normal environmental variables

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
    • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

False positive for "Screen Lock When System Is Idle" on Mac Mojave 10.14.4

  • I'm submitting a ...

    • bug report
  • What is the current behavior?
    Related to: #135
    and #136

On Mac Mojave 10.14.4 with Stethoscope v3.0.4 I'm getting a green check mark and it says "Screen will lock when the system is idle for too long" even though that is disabled in the system control panel.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  1. Choose System Preferences from the Apple menu.
  2. Click Desktop & Screen Saver.
  3. Click the Screen Saver tab.
  4. Adjust the "Start after" dropdown to "never"
  5. Click "Rescan" on Stethoscope
  • What is the expected behavior?
    It should show a red X, and say "Screen will NOT lock when the system is idle for too long"

  • What is the motivation / use case for changing the behavior?
    Users might be tricked into believing their system is secure when it's not.

  • Please tell us about your environment:

    • Stethoscope Version: v3.0.4

    • Platform:

      • Mac Mojave 10.14.4
    • Browser: [x] Chrome Version 73.0.3683.103 (Official Build) (64-bit)

  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Screenshot showing the bug:
screen lock when system is idle bug

Current yarn.lock is incompatible with latest electronuserland/builder:wine Docker image

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

Attempting to use the latest version of electronuserland/builder:wine, per these instructions results in a yarn failure, since that Docker image uses Node 11.10.0, and yarn needs at least 11.10.1 to resolve dependencies.

I'm not sure what the release cadence of electron-userland is for these images, but this build failure can be worked around by cloning electron-builder, and changing this Dockerfile line to pin the Node version to 11.10.1, then running the ./docker/build.sh script to build the electron-builder Docker image stack locally. I will note for posterity that there were node-gyp failures attempting to use the default 12.13.1 Node version specified in that Dockerfile, whereas 11.10.1 seemed to work OK.

Feel free to close this, as it is really more of an upstream/dependency issue. Just wanted to surface this for visibility in case others run into the same difficulty.

Remote login enabled should result in a yellow suggestion (vs red warning)

Dropping this here so it doesn't get lost.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    "Remote Login Disabled" should be yellow if remote login is enabled on the machine, not red.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Enable remote login on macOS.

  • What is the expected behavior?

Should be a yellow result, not ned.

  • What is the motivation / use case for changing the behavior?

"Remote Login" is something we want to encourage people to disable if not needed but there are plenty of valid use-cases and we shouldn't block/nag unnecessarily.

  • Please tell us about your environment:

    • Stethoscope Version: 2.0.8
    • Platform:
      • Mac
      • Windows
    • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Manually add Mac patch level when missing

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

Mac sometimes drops the patch level off of OS version (e.g. 10.14.0 => 10.14), which causes the Semver type check to fail.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Be on 10.14.0, 10.13.0, etc. or manually override the value in code. Launch the app and get an error like:

"stack": "TypeError: Invalid Version: 10.14\n    at new G (file:///Applications/Stethoscope.app/Contents/Resources/app.asar/build/static/js/2.fc80a914.chunk.js:1:119244)\n    at se.test 
(file:///Applications/Stethoscope.app/Contents/Resources/app.asar/build/static/js/2.fc80a914.chunk.js:1:130712)\n    at Function.fe [as satisfies] 
(file:///Applications/Stethoscope.app/Contents/Resources/app.asar/build/static/js/2.fc80a914.chunk.js:1:125481)\n    at t.value 
(file:///Applications/Stethoscope.app/Contents/Resources/app.asar/build/static/js/main.d4eab28e.chunk.js:1:13151)\n    at t.value 
(file:///Applications/Stethoscope.app/Contents/Resources/app.asar/build/static/js/main.d4eab28e.chunk.js:1:13360)\n    at t.value 
(file:///Applications/Stethoscope.app/Contents/Resources/app.asar/build/static/js/main.d4eab28e.chunk.js:1:14133)\n    at Ao 
(file:///Applications/Stethoscope.app/Contents/Resources/app.asar/build/static/js/2.fc80a914.chunk.js:1:357303)\n    at Mo 
(file:///Applications/Stethoscope.app/Contents/Resources/app.asar/build/static/js/2.fc80a914.chunk.js:1:357096)\n    at Fo 
(file:///Applications/Stethoscope.app/Contents/Resources/app.asar/build/static/js/2.fc80a914.chunk.js:1:360953)\n    at Wa 
(file:///Applications/Stethoscope.app/Contents/Resources/app.asar/build/static/js/2.fc80a914.chunk.js:1:385055)"
}
  • What is the expected behavior?

Stethoscope handles this gracefully, just add .0 to the end when patch level is missing on Mac.

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows

Issue reported by @erichs

Bundled `kmd` fails when user doesn't have node preinstalled

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

If user doesn't have node installed prior to running application, an error occurs because kmd is relying on it.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Remove node, run Stethoscope - you should see some flavor of GraphQL failing.

  • What is the expected behavior?

Application is self-contained, does not rely on external NodeJS.

  • What is the motivation / use case for changing the behavior?

Working application

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows

secure Wifi networks with SSID containing the name Open make Open Wifi check fail on Mac

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

Screenshot 2020-12-18 at 12 29 27

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Just name a protected Wifi Network OpenSpace and you still see unprotected Wifi warning.

  • What is the expected behavior?

https://github.com/Netflix-Skunkworks/stethoscope-app/blob/master/src/sources/darwin/openWifiConnections.sh checks the correct parameter instead of parsing for the keyword Open.

  • What is the motivation / use case for changing the behavior?

properly detect open wifi networks

  • Please tell us about your environment:

    • Stethoscope Version: master branch
    • Platform:
      • Mac
      • Windows
    • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Check for Updates menu location consistancy

  • I'm submitting a ...

    • bug report
    • feature request
  • What is the current behavior?

On Mac build, "Check for Updates" is under the Stethoscope menu; on Windows it's under the Help menu. I'd like to suggest having Check for Updates appear under Help on Mac as well as under the Stethoscope menu. Makes telling users where to look for it consistent.

  • Please tell us about your environment:

    • Stethoscope Version: 1.2.0
    • Platform:
      • Mac
      • Windows
    • Browser: N/A

False positive for disk encryption on Windows

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

Note this is not a duplicate of #87 as that applies to newer Apple hardware in macOS only.

On Windows with version 2.1.0 disk encryption is reported as enabled when it's not. For myself, I have an external drive with Bitlocker on but the system drive has no encryption (it's a Bootcamp partition and encryption isn't supported). A coworker (who was only using 2.0.4) reported the same issue, and AFAIK they don't have any Bitlocker drives on their system. Neither system shows Bitlocker enabled in the Control Panel.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Run Stethoscope 2.1.0 and note that disk encryption is reported as enabled when it's not.

  • What is the expected behavior?

The encryption check should fail.

  • Please tell us about your environment:

    • Stethoscope Version: 2.1.0
    • Platform:
      • Mac
      • Windows 10, 1809

Linux disk block volume information is spammy

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    For modern Ubuntu systems, Snap-format applications are often used alongside the traditional Debian packages (apt). These applications use squashfs internally as a read-only filesystem, and result in many, many mounted loopback filesystems of type "squashfs" when examined with a command like lsblk, which the kmd script in the linux disk resolver uses.

  • What is the expected behavior?
    Users of Stethoscope almost certainly aren't interested in this volume information when considering the current state of the endpoint's disks. They should be removed from the output.

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
    • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

lastScanTime does not update when /scan is triggered outside of Electron app

  • I'm submitting a ...

    • [x ] bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    If the Origin header is anything other than stethoscope://main, the lastScanTime field does not update when scans are performed.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  1. Edit practices/config.yaml to read:
allowHosts:
  - "stethoscope://main"
  - "stethoscope://test"
hostLabels:
  - pattern: "^http://localhost:3000"
    name: Local Server
  - pattern: "^stethoscope://test"
    name: Non-Electron Scan Test
  1. Start the development server: yarn start

  2. Wait a minute or so.

  3. Exercise the local GraphQL endpoint at http://localhost:37370/scan, making sure to set the Origin header to stethoscope://test.

  • What is the expected behavior?
    The app should say: Last scanned by Non-Electron Scan Test a few seconds ago

Instead, it will read:
Last scanned by Non-Electron Scan Test a minute ago

  • Please tell us about your environment:

    • Stethoscope Version: latest master
    • Platform:
      • Mac
      • Windows

Add support for Windows patches schema

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • feature request
  • Do you want to request a feature or report a bug?

Would be good to support the patch schema in osquery to ensure critical patches are applied

  • What is the current behavior?

No support

  • What is the expected behavior?

Require specific patches to be installed

  • What is the motivation / use case for changing the behavior?

Coverage of Windows vulnerabilities

  • Please tell us about your environment:

Make DMG install action more clear

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

We are currently using the DMG installer with the default background.
stethoscope_3_0_3_and_package_json_ var_www_stethoscope_app __var_www_stethoscope_app

Though many users know what to do when presented with this screen, some double-click on the app icon and launch directly from the DMG. Electron builder has a background property that allows us to specify a custom background image, which should include basic instructions. dmg configuration documentation

  • What is the motivation / use case for changing the behavior?

Preventing issues where users believe they have the app installed, but don't.

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows

Missing instructions for Automatic Updates

  • I'm submitting a ...

    • bug report
  • What is the current behavior?

The instructions under automaticUpdates for darwin end with "Make sure the following are checked:" but do not display the sub bullets

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Click the disclosure triangle for Automatic Updates after a scan completes.

  • Please tell us about your environment:

    • Stethoscope Version: 1.2.5
    • Platform:
      • Mac

Chromium FileReader Vulnerability

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    Open vulnerability: FileReader Vulnerability

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
    See Blog Post

  • What is the expected behavior?
    No vulnerability 😄

  • What is the motivation / use case for changing the behavior?
    Security

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
    • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Packaging practices into folders/modules

First of all I just want to say that I'm a big fan of what you guys are doing!

We in the developer experience team at svt.se are looking at how we could build and use Stethoscope internally and contribute to the upstream project.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

Creating a new practice and activating that in the policy involves changes across the codebase.

As seen in this little hello world policy example: svt@b5f086f

Included polices are then "activated" in the src/practices/policy.yaml

  • Suggested new feature

It would be nice to have a folder that contained all practices src/practices/ and a separate folder for each practice (src/practices/screenLock, src/practices/automaticUpdates etc).

That folder/module could contain all of the strings, resolvers, graphql, tests etc for that practice.

All practices could then be dynamically loaded at build time based on a src/practices/policy.yaml.

The spirit of this is kind of like apps work in the Django framework https://docs.djangoproject.com/en/2.2/intro/tutorial01/#creating-the-polls-app.

  • What is the motivation / use case for changing the behaviour?
  1. We would like to contribute security practices upstream and still be able to add more organization specific security practices without having to deal with too many merge conflicts down the road.

  2. Maybe it would be easier to add a new security practice if you could copy and modify a folder containing everything needed for that practice?

  3. The continuation of this could maybe be to support the packaging and loading practices as npm packages?

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
      • Linux

Potential issue with Open Wifi scan

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    Wifi scan tells me I have open networks, I went to the System Preferences and remove the 3 marked Open. Stethoscope still says I have open networks. And looking at the airport plist file, it contains 300+ total networks, while the preference pane shows 4.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
    I'm not sure if this is a bug or if it's a documentation issue.

  • What is the expected behavior?
    Following the instructions for fixing a failed check should let the check pass.

  • What is the motivation / use case for changing the behavior?

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
    • Browser: N/A
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Screen Shot 2019-07-22 at 12 37 57 PM

I can provide my plist as well if that's helpful.

Add support for browser extensions

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    There is no ability to check for blocked or required browser extensions.
    Given the recent publication of malicious extensions it would be nice to have the ability to look for required or blocked browser extensions.

  • What is the expected behavior?
    Per browser, have the ability to specify extension ids and a requirement state for each, as well as an optional description and installFrom URL.

    • ALWAYS - will result in an error if the extension is not present
    • SUGGESTED - will result in a warning if the extension is not present
    • NOT_SUGGESTED - will result in a warning if the extension is present
    • NEVER - will result in an error if the extension is present

Policy Schema:

browserExtensions:
  chrome:
  - id: extension id
    description: description to be displayed for information on the extension (optional)
    name: extension name (optional)
    installFrom: URL to link user to required extension (optional)
  firefox:
  - id: extension id
    description: description to be displayed for information on the extension (optional)
    name: extension name (optional)
    installFrom: URL to link user to required extension (optional)
  ...
  • What is the motivation / use case for changing the behavior?
    To provide a better view and provide remediations into the user's browser extensions.

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
      • Linux
    • Browser: [Chrome | Firefox | IE | Safari]

How to find Chrome extensions
How to find Firefox extensions

Applications should support platform filter

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    The requiredApplications mechanism from 3.0 series supported a platform filter:

    platform: PlatformStringRequirement
    .

This enabled one policy to span multiple OS platforms, and the version and installation assertions would only apply if Stethoscope was running on the listed platform.

The new mechanism does not appear to support this:

input ApplicationRequirement {
name: String! # e.g. Slack.app
paths: ApplicationPaths
version: Semver
assertion: RequirementOption! # ALWAYS, NEVER, SUGGESTED, etc.
description: String
installFrom: String
}

  • Please tell us about your environment:
    As this is a breaking GraphQL schema change, it affects all platforms. Additionally, the Platform-specific resolvers should have code added to filter out and resolve only the ApplicationRequirements specific to their platform. The WindowsSecurity resolver currently appears to try to account for this:
    return applications.filter((app) => {
    const { platform = false } = app
    // if a platform is required
    if (platform) {
    if (platform[devicePlatform]) {
    return semver.satisfies(osVersion, platform[devicePlatform])
    }
    return platform.all
    }
    // no platform specified - default to ALL
    return true
    }).map(({
    (though I have only quickly glanced at this code)
  • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
    • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Expand first non-passing issue.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

All items are collapsed, whether passing or failing.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Turn firewall/automatic updates off temporarily and rescan to see the current behavior.

  • What is the expected desired behavior?

It would be nice to expand the first non-passing item for the user so they see instructions on how to fix what is wrong with their machine and don't have to search/intuit out that instructions can be expanded.

  • What is the motivation / use case for changing the behavior?

Clarity

  • Please tell us about your environment:

    • Stethoscope Version:
    • Platform:
      • Mac
      • Windows
    • Browser: all

SemVer comparison not working as expected

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

OS version comparison is not working as expected. Tested on Windows.

Policy configured:

...
  win32:
    ok: ">=10.0.18363"
    nudge: ">=10.0.17763"
...

Windows OS Version: 10.0.19041

Screenshot:
Capture

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Add the policy mentioned in the bug report.
Run stethoscope on Windows with the latest OS Version 10.0.19041.

  • What is the expected behavior?

Pass the policy configured with the latest OS Version.

  • Please tell us about your environment:

    • Stethoscope Version: 5.0.0
    • Platform:
      • Mac
      • Windows
    • Browser: all
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Is this project still active?

I was wondering if this project is still being actively developed and used by Netflix and, if that's not the case, what tool has been chosen to replace it.

The code frequency graph is flat since 2020 and there is no activity in Gitter since 2021-01-28, and also I've tried to contact [email protected] on 2022–02–20 without success.


Note: sent another message to [email protected] on 2022–03–01 hoping for a reply.

requiredApplications is not functional

  • I'm submitting a ...

    • bug report
  • What is the current behavior?

When attempting to use required applications we receive Device.applications is not a function.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

You can cause this by attempting to use required applications policy key inside of policy.yaml

required applications:
- name: Google Chrome

You can attempt to console the Device object.

  async requiredApplications (root, args, context) {
    console.log(Device)
    const applications = await Device.applications(root, args, context)
    ...
    ...
  }
  • What is the expected behavior?

It should return a non-empty object.

  • Please tell us about your environment:

    • Stethoscope Version: 1.1.7
    • Platform:
      • [ X ] Mac
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

It appears as though /resolvers/platform/MacSecurity.js file isn’t properly importing Device from /resolvers/Device.js. If I just console.log Device within MacSecurity it just outputs an empty object {}. I looked into this issue and I’m assuming it might be a circular dependency according to this stackoverflow post: https://stackoverflow.com/questions/23875233/require-returns-an-empty-object/23875299

Updated instructions for "Automatic Updates are enabled" for macOS Mojave

  • I'm submitting a ...

    • bug report
  • What is the current behavior?

Currently in macOS Mojave the instructions say to go to the App Store preference pane. In Mojave this has changed to a new Software Update preference pane.

screenshot 2018-08-23 12 44 23

Here's the Advanced options as well:
screenshot 2018-08-23 12 44 29

  • Please tell us about your environment:

    • Stethoscope Version: 1.2.5
    • Platform:
      • Mac

Ubuntu issue

I ran this on my ubuntu desktop, my firewall is enabled but the application doesn't detect that it is.
All the other checks ran and completed with green checks.
I did run 'sudo ufw status' to make sure it was running.

Here is my system:
Linux kitfox-laptop 4.18.11-041811-generic #201809290731 SMP Sat Sep 29 11:33:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

  • Stethoscope Version: v2.0.8
  • Platform:
    • Ubuntu
    • Mac
    • Windows
  • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

False positive for Automatic Updates on Mac Mojave 10.14.4

  • I'm submitting a ...

    • bug report
  • What is the current behavior?
    Related to: #135

On Mac Mojave 10.14.4 with Stethoscope v3.0.4 I'm getting a green check mark and it says "Automatic updates are enabled" even though they are not enabled in the system control panel.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  1. Choose System Preferences from the Apple menu.
  2. Click Software Update
  3. Uncheck "Automatically check for updates"
  4. Click "Rescan" on Stethoscope
  • What is the expected behavior?
    It should show a red X, and say "Automatic updates are enabled"

  • What is the motivation / use case for changing the behavior?
    Users might be tricked into believing their system is secure when it's not.

  • Please tell us about your environment:

    • Stethoscope Version: v3.0.4

    • Platform:

      • Mac Mojave 10.14.4
    • Browser: [x] Chrome Version 73.0.3683.103 (Official Build) (64-bit)

  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Screenshot showing the automatic updates bug:
automatic updates bug

False positive for disc encryption on a Mac

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

Staff member installed Stethoscope on her brand new MacBook Air. It's reporting that disc encryption is on while FileVault says it is not on.

screen shot 2018-12-14 at 3 00 04 pm

  • What is the expected behavior?

If FileVault is not enabled, disc encryption check should fail.

  • Please tell us about your environment:

    • Stethoscope Version: 2.0.3
    • Platform:
      • Mac
      • Windows
    • Browser: irrelevant
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

False positive for screen lock on Mac Mojave 10.14.4

  • I'm submitting a ...

    • bug report
  • What is the current behavior?
    On Mac Mojave 10.14.4 with Stethoscope v3.0.4 I'm getting a green check mark and it says "Screen Lock is enabled" even though it is not enabled in the system control panel.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  1. Choose System Preferences from the Apple menu.
  2. Click Security or Security & Privacy.
  3. Select the General tab.
  4. Unlock the pane by clicking the lock in the lower-left corner and enter the administrator username and password.
  5. UnCheck the "Require password" box.
  6. Click "Rescan" on Stethoscope
  • What is the expected behavior?

It should show a red X, and say "Screen Lock is disabled"

  • What is the motivation / use case for changing the behavior?

Users might be tricked into believing their system is secure when it's not.

  • Please tell us about your environment:

    • Stethoscope Version: v3.0.4

    • Platform:

      • Mac Mojave 10.14.4
    • Browser: [x] Chrome Version 73.0.3683.103 (Official Build) (64-bit)

  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

I will also submit two other related bugs, showing the same problem related to "automatic updates" and "screen lock when the system is idle."

Screenshot showing the screen lock bug:
Screen Lock OFF BUG

Screenshot showing the firewall status is working as intended:
Firewall off - Working as intended

ScreenIdle FeatureState

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the motivation / use case for changing the behavior?

Many compliance frameworks have requirements around idle lockout, where the screensaver locks after some duration.

  • Please tell us about your environment:

    • Stethoscope Version: 2.0.5
    • Platform:
      • Mac
      • Windows
      • Linux
    • Browser: [all]
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

On Mac, this may be implemented almost identically to the existing screenLock resolver, with the exception that the idleTime field is available via osquery even on High Sierra.

In terms of schema, this might be:

screenIdle: String

and configured perhaps like:

...
screenLock: IF_SUPPORTED
screenIdle: "120"
...

osquery results for this field less than or equal to the policy would PASS. Perhaps a semver-like "<=120" syntax could be supported.

Missing deviceName field on Mac

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    deviceName is ""

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
    query ValidateDevice with the app in development mode, observe the output like:

   "device": {
      "deviceId": "<redacted>",
      "deviceName": "",
      "platform": "darwin",
      "platformName": "Apple Inc.",
      "osVersion": "10.12.6",
  • What is the expected behavior?
    deviceName should not be empty string. This occurs because computer_name from osquery system_info table is null.

  • What is the motivation / use case for changing the behavior?

  • Please tell us about your environment:

    • Stethoscope Version: 2.1.0
    • Platform:
      • Mac
      • Windows
    • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

osqueryd_version: 3.3.0
osx: 10.12.6

v2.1.0 fails to run on Win10

Note: for support questions, please email us or contact us on Gitter. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    running yarn build:windows fails to launch Stethoscope during Spectron tests, WMI Provider host task consumes 100% CPU, and system becomes unresponsive.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Windows 10 Pro, Version 1803, build 17134.523
Node v10.15.1 LTS
checkout master
yarn build:windows

  • What is the expected behavior?
    Stethoscope should launch

  • What is the motivation / use case for changing the behavior?

  • Please tell us about your environment:

    • Stethoscope Version: 2.1.0
    • Platform:
      • Mac
      • Windows
    • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Several black console host windows spawn, and seem to hang. The electron dialog never really fully loads, but does eventually throw up a dialog showing a 404 attempting to discover the latest release in latest.yml. Since I did not provide a custom build.publish stanza in package.json, this results in the Electron app attempting to download from https://github.com/Netflix-Skunkworks/stethoscope-app/downloads/v2.1.0/... which is, indeed, a 404.

I'm not sure if the above is a red-herring, as I imagine it would be non-blocking. I suspect there may be something going on with osqueryd.exe initialization, as I saw many "console host" and "taskkill.exe" processes in task manager during this.

Add daily check for app update

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

App checks for updates on launch and when user manually selects "Check for Update" from menu. For users who leave the app running (hopefully most users), they may not be prompted to install important updates when they are available.

  • What is the expected behavior?

App checks for updates in the background at a regular interval

  • What is the motivation / use case for changing the behavior?

Ensuring users have the latest version.

  • Please tell us about your environment:

    • Stethoscope Version: 3.0.4
    • Platform:
      • Mac
      • Windows
      • Linux

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.