Command Line Utility for Phylum

The command line interface (CLI) allows users to submit their project package dependencies to Phylum's API for analysis


Introduction

The command line interface (CLI) allows users to submit their project package dependencies to Phylum's API for analysis. Currently pre-built binaries for Linux and macOS are available. For other platforms (e.g., Windows), binaries can easily be built.

Quickstart for Linux or macOS

  1. Download the latest release package for your target:

    Target Package
    x86_64-unknown-linux-musl phylum-x86_64-unknown-linux-musl.zip
    x86_64-apple-darwin phylum-x86_64-apple-darwin.zip
    aarch64-apple-darwin phylum-aarch64-apple-darwin.zip
  2. Confirm the signature of the archive with minisign and the public key for Phylum

  3. Unzip the archive

  4. Run the installer script for installation

  5. Register for an account (if you don't already have one)

  6. Authenticate with Phylum

  7. Create a new Phylum project in your project directory

  8. Submit your package lock file


Questions/Issues

Please contact Phylum with any questions or issues using the CLI tool.

Email: [email protected]

Issues

Collection of the latest Issues

mathew-horner

mathew-horner

enhancement
3

Overview

I recently implemented a new API endpoint for redirecting to the Keycloak OpenID configuration. We need to update the CLI to consume this instead of using the oidc_discovery_url config value.

Acceptance Criteria

  • All usages of the oidc_discovery_url config value should be replaced by the API endpoint /.well-known/openid-configuration.
  • The CLI user should not have to specify the oidc_discovery_url config value anymore.
cd-work

cd-work

enhancement
0

Overview

Currently the Phylum CLI only supports parsing the output of gradle dependencies as lockfile, however this format is made for consumption by humans. Instead, support for the gradle.lockfile format should be added, which is a proper lockfile generated by Gradle itself.

Since it seems like there's no user of the existing gradle "lockfile" parser, I'd also strongly suggest removing it before people start relying on the Phylum CLI being able to parse this rather arbitrary and prone-to-change format.

Acceptance Criteria

  • Phylum CLI correctly identifies gradle.lockfile
  • All packages from the gradle.lockfile and their version are submitted to the API as Maven dependencies
  • Support for gradle dependencies parsing is removed
andreaphylum

andreaphylum

enhancement
0

Overview

Currently, the test for the availability of an extension from inside the CLI doesn't validate that the extension is actually run, only that it is available from the CLI. We want to test that a fixture extension works correctly.

Acceptance Criteria

  • An integration test that checks that a fixture extension, when run, emits a known output passes.
andreaphylum

andreaphylum

enhancement
3

Currently, phylum extension add will install extensions from a local directory.

In the future, we may have a marketplace of extensions and it would make more sense that phylum extension add <ext> adds an extension from there, so we may want to add a --local flag to the CLI subcommand to retain the current behavior.

andreaphylum

andreaphylum

enhancement
1

We're currently using the XDG specification's file structure, which will fall back on using ~/.local under Windows. We may want to comply with Windows' convention of using the %APPDATA% and/or %LOCALAPPDATA% locations instead.

kylewillmon

kylewillmon

bug
4

Overview

A small typo in the filename for the lockfile is an easy mistake to make. But the error message output by phylum analyze is very unhelpful and says nothing about the file being nonexistent.

Expected Behavior

An error message that says something like "file not found"

Additional Context

I'm asking for a freind of course... I have no truoble at all with my spelling 😅

andreaphylum

andreaphylum

enhancement
0

Overview

The user should be able to add, remove and list extensions via the appropriate phylum extension subcommand.

Acceptance Criteria

  • When a user runs phylum extension add . the extension in the current working directory should be installed.
  • After a user installs a new extension, foobar, it should become available to the user under the phylum cli, e.g., running phylum foobar should execute the foobar extension.
  • When a user installs a valid extension it should print a message indicating success. It should also print a quick guide on the extension to give the user some context on how the given extension works.
  • When a user attempts to install an invalid extension, it should fail and inform the user as to why.
  • When a user runs phylum extension remove <extensionName> the extension should be entirely removed from the user system.
  • When a user runs phylum extension or phylum extension list a list of currently installed extensions, their versions and a short one sentence blurb on what the extension does should be shown in a table format.

Associated User Story

#404

kylewillmon

kylewillmon

bug
2

When a threshold is disabled in the UI, but not also set to 0, the CLI shows this threshold as enabled. For example:

disabled

Conversely, if the threshold is enable in the UI, but set to a value of 0, the CLI shows this as Not Set.

Expected Behavior

The CLI should show Not Set if and only if the threshold is actually disabled

kylewillmon

kylewillmon

enhancement
1

When phylum update is run, it will:

  1. Confirm that the user is on a platform that supports self-update (i.e, aarch64-apple-darwin, x86_64-apple-darwin, or x86_64-unknown-linux).
  2. Attempt an escape hatch update (details below)
  3. Perform the steps exactly as explained for a fresh install here (i.e., download the zip, verify the signature, unzip it, and run ./install.sh)

Escape hatch update

To ensure that phylum update continues to work in the future even if we change our install process and/or release layout again, I will add an "escape hatch". Here are the steps I propose for the escape hatch:

  1. Do an HTTP GET of #404 and #404.minisig
  2. If there is a 404 error or DNS error, go back to the normal install steps
  3. If files are return, verify the signature and run update.sh to perform the update.

Originally posted by @kylewillmon in https://github.com/phylum-dev/cli/issues/187#issuecomment-1087583649

kylewillmon

kylewillmon

enhancement
0

Overview

Support the Windows platform by releasing CLI binaries for Windows and implementing a self-update capability for Windows clients.

Acceptance Criteria

  • Instructions for installing on Windows in docs
  • phylum update works on Windows
maxrake

maxrake

enhancement
1

Overview

Recent updates to the CLI install script included adhering to standards as provided by the shellcheck QA tool. However, these standards can drift back out of compliance as future work occurs in the project. To combat this, the project should:

  • add shellcheck to CI
    • Use version 0.8.0 or newer in order to make use of the -o all option
  • fail builds when not adhering to the strict standards
  • consider adding pre-commit options for developers
  • add documentation or pointers on how to add shellcheck scanning to IDE(s)

Originally suggested by @kylewillmon in https://github.com/phylum-dev/cli/issues/214#issuecomment-1079072318

Acceptance Criteria

  • All shell scripts in the repo are scanned with shellcheck in CI
  • The CI checks fail when there are QA findings
  • The shell checks occur automatically for PRs and pushing to the development and master branches
  • The shell checks can be triggered manually

Associated User Story

--

maxrake

maxrake

enhancement
0

Overview

Currently, the Phylum CLI binary is signed using minisign and the private key for Phylum. This signature can be verified using the corresponding public key for Phylum:

However, it is not clear that RWT6G44ykbS8GABiLXrJrYsap7FCY77m/Jyi0fgsr/Fsy3oLwU4l0IDf is the public key for Phylum to the casual user and the instructions for performing this signature verification only provide the full key text and not an example of using a key file.

Further, the source of the (currently) published public key (i.e., the GitHub docs) is the same as the binaries it is meant to verify. In the absence of Certificate Authorities (CAs) to confirm the signer's identity, security best practices indicate that "the public key must instead be distributed using a trusted, out-of-band mechanism."

Acceptance Criteria

  • Phylum minisign public key provided in an out of band channel that is also know to be controlled by Phylum
  • Public key plaintext and key file provided for user's preferred method of verification
  • Documentation updated to make the process of code/signature verification more clear

Associated User Story

None currently...but perhaps one for the website and/or UI...as a potential "external" location for storing the public key?

louislang

louislang

enhancement
0

Overview

Users should be able to run phylum fix <pkg-lock-file> to address issues in their projects. The fix subcommand should attempt to maximize the user score by remediating as many issues as possible. Fixes should update the package file(s).

There should be a few options for the fix subcommand:

  • phylum fix <pkg-file> <issue-id> Fix all issues of the given issue id in a project
  • phylum fix <pkg-file> <issue-id> <[email protected]> Fix the specified issue for the specific dependency

Acceptance Criteria

  • The CLI should implement a new subcommand phylum fix with support for specifying issue IDs and specific dependencies
  • The CLI should take a path to a package lock file
  • Given a package lock file that does not exist or is inaccessible we should clearly notify the user
  • Given a valid package lock path, we should submit it to the API for possible fixes and remediations (see: https://github.com/phylum-dev/api/issues/156)
  • Fixes and remediations received from the API should be applied to the specified package lock file
  • Any issues that are unable to be remediated should be displayed to the user
  • The user should be prompted before proposed fixes are made to their package lock file
  • If multiple fixes exist for a specific issue, prompt the user to select an option
  • By default, and with no other options, phylum fix will attempt to fix the most issues to maximize the user score.
  • Once a fix has been applied, prompt user of any next steps. For example, in NPM we might update the package.json file, but the user should be responsible for updating their package-lock.json file. We might instruct them to “Fixes have been applied and your package.json file has been updated! Run npm install --package-lock-only to generate a new package lock file”.
furi0us333

furi0us333

bug
1

Describe the bug The Crit field is shown in the history view, but is not populated with any data.

To Reproduce Steps to reproduce the behavior:

  1. Have analyzed at least one project
  2. Run phylum history
  3. Observe the "Crit:" field

Expected behavior Either remove this field or populate it with the correct data.

Screenshots image

Versions

Find the latest versions by id

v3.3.0 - May 16, 2022

Added

Fixed

Full Changelog: https://github.com/phylum-dev/cli/compare/v3.2.0...v3.3.0

v3.3.0-rc2 - May 16, 2022

v3.3.0-rc1 - May 11, 2022

v3.2.0 - May 06, 2022

Added

Fixed

New Contributors

Full Changelog: https://github.com/phylum-dev/cli/compare/v3.1.0...v3.2.0

v3.1.0 - Apr 29, 2022

Added

Fixed

Full Changelog: https://github.com/phylum-dev/cli/compare/v3.0.0...v3.1.0

v3.1.0-rc1 - Apr 29, 2022

v3.0.0 - Apr 28, 2022

BREAKING CHANGES

Added

Fixed

Deprecated

New Contributors

Full Changelog: https://github.com/phylum-dev/cli/compare/v2.2.0...v3.0.0

v3.0.0-rc2 - Apr 28, 2022

v3.0.0-rc1 - Apr 27, 2022

v2.2.0 - Apr 21, 2022

Added

Fixed

Full Changelog: https://github.com/phylum-dev/cli/compare/v2.1.0...v2.2.0

v2.2.0-rc1 - Apr 19, 2022

v2.1.0 - Apr 13, 2022

What's Changed

Full Changelog: https://github.com/phylum-dev/cli/compare/v2.0.1...v2.1.0

v2.0.2-rc2 - Apr 12, 2022

v2.0.2-rc1 - Apr 12, 2022

v2.0.1 - Apr 12, 2022

What's Changed

New Contributors

Full Changelog: https://github.com/phylum-dev/cli/compare/v2.0.0...v2.0.1

v2.0.1-rc1 - Apr 11, 2022

v2.0.0 - Apr 11, 2022

What's Changed

New Contributors

Full Changelog: https://github.com/phylum-dev/cli/compare/v1.2.0...v2.0.0

v2.0.0-rc1 - Apr 09, 2022

v1.3.0-rc9 - Mar 29, 2022

v1.3.0-rc5 - Mar 29, 2022

v1.3.0-rc4 - Mar 11, 2022

v1.3.0-rc3 - Mar 11, 2022

v1.3.0-rc2 - Mar 10, 2022

v1.3.0-rc1 - Mar 09, 2022

v1.2.0 - Jan 22, 2022

What's Changed

New Contributors

Full Changelog: https://github.com/phylum-dev/cli/compare/v1.1.4...v1.2.0

v1.2.0-rc4 - Jan 20, 2022

v1.2.0-rc3 - Jan 14, 2022

v1.2.0-rc2 - Jan 13, 2022

v1.1.5 - Dec 06, 2021

v1.2.0-rc1 - Dec 01, 2021

What's Changed

Full Changelog: https://github.com/phylum-dev/cli/compare/v1.1.3...v1.2.0-rc1

Information - Updated May 18, 2022

Stars: 13
Forks: 5
Issues: 24

Repositories & Extras

Rust bindings for libinjection

Add libinjection to dependencies of Cargo

Rust bindings for libinjection

Rocket is an async web framework for Rust with a focus on usability, security,

Visiting localhost:8000/hello/John/58, for example, will trigger the hello

Rocket is an async web framework for Rust with a focus on usability, security,

Rust bindings for the C++ api of PyTorch

LIghtweight wrapper for pytorch eg libtorch in rust

Rust bindings for the C++ api of PyTorch

Know the exact crate versions used to build your Rust executable

Audit binaries for known bugs or security vulnerabilities in production, at scale, with zero bookkeeping

Know the exact crate versions used to build your Rust executable

macOS/iOS Security framework for Rust

MIT license (LICENSE-MIT or

macOS/iOS Security framework for Rust

Reference implementation of the Stacks blockchain in Rust

Reference implementation of the Proof of Transfer (PoX) mining that anchors to Bitcoin security

Reference implementation of the Stacks blockchain in Rust

osu! server written in Rust

Fully asynchronous, high concurrency, high performance, and high security

osu! server written in Rust

Nakamoto is a privacy-preserving Bitcoin light-client implementation in Rust,

with a focus on low resource utilization, modularity and security

Nakamoto is a privacy-preserving Bitcoin light-client implementation in Rust,

A WIP Rust implementation of Messaging Layer Security based on draft 9+

Messaging Layer Security based on draft 9+

A WIP Rust implementation of Messaging Layer Security based on draft 9+

Rust Language Security

execrices: RUSTSEC-2021-0001

Rust Language Security

security-keys-rust

Many thanks to the authors of the openpgp-card Rust crate

security-keys-rust

Owlyshield open source security platform

An OSS security platform written in rust with security threat detection

Owlyshield open source security platform
Facebook Instagram Twitter GitHub Dribbble
Privacy