sonatype-nexus-community / cargo-pants Goto Github PK
View Code? Open in Web Editor NEWLicense: Apache License 2.0
License: Apache License 2.0
Comment from a prior PR
IDEA is flagging this (line 74 - not shown in diff), but it I'm not sure it makes sense to me.
Error
doesn't implementDisplay
(required by {})
Follow up on the comment from here and investigate if there are any issues with our current implementation.
Vulnerabilities
DepShield reports that this application's usage of arc-swap:0.4.8 results in the following vulnerability(s):
Occurrences
arc-swap:0.4.8 is a transitive dependency introduced by the following direct dependency(s):
• log4rs:1.0.0
└─ arc-swap:0.4.8
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
While configuring for use with IQ, I was seeing errors like those below:
...
🦀 Obtained package list (148)
🦀 SBOM generated
❌ Error generating Nexus IQ Server results
error decoding response body: expected value at line 1 column 1
with the log showing:
{"timestamp":"2021-11-16T16:52:23.802917Z","level":"ERROR","fields":{"message":"error decoding response body: expected value at line 1 column 1"},"target":"cargo_iq"}
There was no clear indication (at least not clear to me) that the cause of the failure was I had forgotten to add the --iq-token
parameter. I think it would be helpful if the error message for this sort of failure gave more help stating the true cause of the failure (e.g. credentials).
The project could not be analyzed because of build errors. Please review the error messages here. Another build will be scheduled within 24 hours. If the build is successful this issue will be closed, otherwise the error message will be updated.
This is an automated GitHub Issue created by Sonatype DepShield. GitHub Apps, including DepShield, can be managed from the Developer settings of the repository administrators.
Vulnerabilities
DepShield reports that this application's usage of rand_chacha:0.3.1 results in the following vulnerability(s):
Occurrences
rand_chacha:0.3.1 is a transitive dependency introduced by the following direct dependency(s):
• mockito:0.30.0
└─ rand:0.8.4
└─ rand_chacha:0.3.1
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Vulnerabilities
DepShield reports that this application's usage of rand_hc:0.1.0 results in the following vulnerability(s):
Occurrences
rand_hc:0.1.0 is a transitive dependency introduced by the following direct dependency(s):
• reqwest:0.9.24
└─ uuid:0.7.4
└─ rand:0.6.5
└─ rand_hc:0.1.0
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Vulnerabilities
DepShield reports that this application's usage of time:0.1.43 results in the following vulnerability(s):
Occurrences
time:0.1.43 is a transitive dependency introduced by the following direct dependency(s):
• log4rs:1.0.0
└─ chrono:0.4.19
└─ time:0.1.43
• reqwest:0.9.24
└─ cookie:0.12.0
└─ time:0.1.43
└─ cookie_store:0.7.0
└─ cookie:0.12.0
└─ time:0.1.43
└─ time:0.1.43
└─ hyper:0.12.36
└─ time:0.1.43
└─ hyper-tls:0.3.2
└─ hyper:0.12.36
└─ time:0.1.43
└─ time:0.1.43
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Thanks for creating an issue! Please fill out this form so we can be
sure to have all the information we need, and to minimize back and forth.
We (meaning Jeffry) tried to get CircleCI building, and got it working, but the release portion to crates.io
is currently broken, and this is largely due to an issue with using git and ssh together, and an underlying downstream library rust-crates-index
which doesn't handle that very well
Getting the work out there!
Look at alternatives to using cargo-release
since it's what uses rust-crates-index
, it is likely we can just rely on cargo-publish
and bump the version number in our Cargo.toml
by hand using sed or something akin.
Nope! Success is new tags to main
branch (whatever it is) end up getting released to crates.io
, likely via a new tag being created and then the workflow kicking off (I believe this is already in place)
Add support for a exclude-vulnerability-file
CLI option. Will be a (default .pants-ignore
) file containing the path to a file containing newline separated CVEs or OSS Index IDs to be excluded.
Similar to how Nancy does it.
Vulnerabilities
DepShield reports that this application's usage of rand_isaac:0.1.1 results in the following vulnerability(s):
Occurrences
rand_isaac:0.1.1 is a transitive dependency introduced by the following direct dependency(s):
• reqwest:0.9.24
└─ uuid:0.7.4
└─ rand:0.6.5
└─ rand_isaac:0.1.1
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Thanks for creating an issue! Please fill out this form so we can be
sure to have all the information we need, and to minimize back and forth.
For a found vulnerability on a library, we probably want to output it in a much easier to read way
^^^ From Nancy, if multiple vulns are found, we'd output it in recurring tables and adjust the number foundThe title of the vuln can be switched to be a color that reflects the severity of the vulnerability, as well as the title of the package. Some code from Nancy can help inform this: https://github.com/sonatype-nexus-community/nancy/blob/master/audit/auditlogtextformatter.go#L116-L141
Just makes it easier to read what is going on and easier to visually scan.
Not sure. Have fun!
Probably want to use a library that disables color on terminals that do not support it, or via a flag such as --no-color
for people who might be color blind!
Vulnerabilities
DepShield reports that this application's usage of smallvec:0.6.14 results in the following vulnerability(s):
Occurrences
smallvec:0.6.14 is a transitive dependency introduced by the following direct dependency(s):
• reqwest:0.9.24
└─ hyper:0.12.36
└─ tokio:0.1.22
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-udp:0.1.6
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-uds:0.2.7
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ hyper-tls:0.3.2
└─ hyper:0.12.36
└─ tokio:0.1.22
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-udp:0.1.6
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-uds:0.2.7
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio:0.1.22
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-udp:0.1.6
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-uds:0.2.7
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
• tokio-core:0.1.18
└─ tokio:0.1.22
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-udp:0.1.6
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-uds:0.2.7
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ parking_lot_core:0.6.2
└─ smallvec:0.6.14
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Vulnerabilities
DepShield reports that this application's usage of crossbeam-queue:0.2.3 results in the following vulnerability(s):
Occurrences
crossbeam-queue:0.2.3 is a transitive dependency introduced by the following direct dependency(s):
• reqwest:0.9.24
└─ hyper:0.12.36
└─ tokio:0.1.22
└─ tokio-fs:0.1.7
└─ tokio-threadpool:0.1.18
└─ crossbeam-queue:0.2.3
└─ tokio-threadpool:0.1.18
└─ crossbeam-queue:0.2.3
└─ tokio-threadpool:0.1.18
└─ crossbeam-queue:0.2.3
└─ hyper-tls:0.3.2
└─ hyper:0.12.36
└─ tokio:0.1.22
└─ tokio-fs:0.1.7
└─ tokio-threadpool:0.1.18
└─ crossbeam-queue:0.2.3
└─ tokio-threadpool:0.1.18
└─ crossbeam-queue:0.2.3
└─ tokio-threadpool:0.1.18
└─ crossbeam-queue:0.2.3
└─ tokio:0.1.22
└─ tokio-fs:0.1.7
└─ tokio-threadpool:0.1.18
└─ crossbeam-queue:0.2.3
└─ tokio-threadpool:0.1.18
└─ crossbeam-queue:0.2.3
└─ tokio-threadpool:0.1.18
└─ crossbeam-queue:0.2.3
• tokio-core:0.1.18
└─ tokio:0.1.22
└─ tokio-fs:0.1.7
└─ tokio-threadpool:0.1.18
└─ crossbeam-queue:0.2.3
└─ tokio-threadpool:0.1.18
└─ crossbeam-queue:0.2.3
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
When calling cargo-iq
and when vulnerabilities exist, the code that prints out the "Inverse dependency graph" will fail.
The root cause appears to be IQ is adding a suffix (?type=crate
) to the purl in the returned IQ results. (Stack trace below).
Can probably fix this issue by removing this suffix before attempting to read the purl from the component map.
Package URL: pkg:cargo/[email protected]?type=crate
Known violations: Security-High
Inverse Dependency graph
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/parse.rs:191:47
stack backtrace:
0: rust_begin_unwind
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
1: core::panicking::panic_fmt
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
2: core::panicking::panic
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:48:5
3: core::option::Option<T>::unwrap
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/option.rs:775:21
4: <cargo_pants::parse::ParseCargoToml as cargo_pants::parse::ParseToml>::print_the_graph
at ./src/parse.rs:191:22
5: cargo_iq::print_iq_policy_violations
at ./src/bin/iq/main.rs:229:29
6: cargo_iq::main
at ./src/bin/iq/main.rs:119:37
7: core::ops::function::FnOnce::call_once
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Thanks for creating an issue! Please fill out this form so we can be
sure to have all the information we need, and to minimize back and forth.
It responds with:
$ cargo pants
Usage:
/Users/michael/.cargo/bin/cargo-pants [OPTIONS]
/Users/michael/.cargo/bin/cargo-pants: Unexpected argument pants
What feature or behavior is this required for?
Basic functionality
How could we solve this issue? (Not knowing is okay!)
It looks as if something is wrong with the argument parsing
Anything else?
Version 0.0.4 seems to work fine, so it is a change in the latest code.
Running cargo-pants works fine.
Thanks for creating an issue! Please fill out this form so we can be
sure to have all the information we need, and to minimize back and forth.
When outputting results for cargo-pants
, make it so it only outputs the libraries with found vulnerabilities, and a summary table, and the masthead. If someone were to pass --loud
to cargo-pants
, then you can also output the full list of libraries scanned. You can group these with:
Non vulnerable packages
[1/X] pkg:cargo/name@version
[2/X] pkg:cargo/name@version
[3/X] pkg:cargo/name@version
Vulnerable packages
[1/X] pkg:cargo/name@version
1 known vulnerability found
VULN
[2/X] pkg:cargo/name@version
2 known vulnerability found
VULN
VULN
It was something we discovered in user testing chelsea
that someone consuming this tool is more interested in what it found, and not the entirety of what it scanned.
Probably some fun overall.
Have a blast!
Vulnerabilities
DepShield reports that this application's usage of traitobject:0.1.0 results in the following vulnerability(s):
Occurrences
traitobject:0.1.0 is a transitive dependency introduced by the following direct dependency(s):
• log4rs:1.0.0
└─ typemap:0.3.3
└─ unsafe-any:0.4.2
└─ traitobject:0.1.0
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Vulnerabilities
DepShield reports that this application's usage of rand_chacha:0.1.1 results in the following vulnerability(s):
Occurrences
rand_chacha:0.1.1 is a transitive dependency introduced by the following direct dependency(s):
• reqwest:0.9.24
└─ uuid:0.7.4
└─ rand:0.6.5
└─ rand_chacha:0.1.1
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Thanks for creating an issue! Please fill out this form so we can be
sure to have all the information we need, and to minimize back and forth.
Similar to nancy
, you can cache the results of reaching out to OSSIndex, to prevent rate limiting. These results should be cached for 12 hours, and then removed from the cache if that TTL has expired.
It will hopefully help people avoid hitting rate limits.
@jdillon can likely share some info on this, there's a generic implementation for what Jason did with our Java tooling, this can likely follow that.
At a minimum your API probably needs:
Likely it would be nice to make the TTL configurable, but the default should be 12 hours.
The cache should be saved at ~/.ossindex/cargo-pants
so that it's in a common location.
Potentially look at: https://docs.rs/pickledb/0.4.1/pickledb/ or https://docs.rs/tinydb/0.0.7/tinydb/
Thanks for creating an issue! Please fill out this form so we can be
sure to have all the information we need, and to minimize back and forth.
We should bring this in to alignment with the other tools and output a:
cargo-pants
By Sonatype & Friends
cargo-pants version: CURRENT_VERSION
It's branding, someone in marketing will probably love this.
My gut says to look for a ascii art library and have some fun!
This should be fun!
Thanks for creating an issue! Please fill out this form so we can be
sure to have all the information we need, and to minimize back and forth.
Provide a summary of what was scanned and what was found:
^^^ from Nancy, likely crafting something similar would be idealIt just gives some quick information to someone consuming the output of cargo-pants
and let's them know if they should visually scan
No clue, good luck!
Have fun!
Thanks for creating an issue! Please fill out this form so we can be
sure to have all the information we need, and to minimize back and forth.
What are you trying to do?
Output in json
format
What feature or behavior is this required for?
Adding a flag to the binary, like --json
and render the information in that format
How could we solve this issue? (Not knowing is okay!)
Anything else?
Vulnerabilities
DepShield reports that this application's usage of rand_os:0.1.3 results in the following vulnerability(s):
Occurrences
rand_os:0.1.3 is a transitive dependency introduced by the following direct dependency(s):
• reqwest:0.9.24
└─ uuid:0.7.4
└─ rand:0.6.5
└─ rand_os:0.1.3
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Vulnerabilities
DepShield reports that this application's usage of futures:0.1.31 results in the following vulnerability(s):
Occurrences
futures:0.1.31 is a transitive dependency introduced by the following direct dependency(s):
• reqwest:0.9.24
└─ futures:0.1.31
└─ hyper:0.12.36
└─ futures:0.1.31
└─ futures-cpupool:0.1.8
└─ futures:0.1.31
└─ h2:0.1.26
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ http-body:0.1.0
└─ futures:0.1.31
└─ tokio-buf:0.1.1
└─ futures:0.1.31
└─ tokio:0.1.22
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-current-thread:0.1.7
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-fs:0.1.7
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-threadpool:0.1.18
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-tcp:0.1.4
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-threadpool:0.1.18
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-timer:0.2.13
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-udp:0.1.6
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-uds:0.2.7
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-buf:0.1.1
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-tcp:0.1.4
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-threadpool:0.1.18
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-timer:0.2.13
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ want:0.2.0
└─ futures:0.1.31
└─ hyper-tls:0.3.2
└─ futures:0.1.31
└─ hyper:0.12.36
└─ futures:0.1.31
└─ futures-cpupool:0.1.8
└─ futures:0.1.31
└─ h2:0.1.26
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ http-body:0.1.0
└─ futures:0.1.31
└─ tokio-buf:0.1.1
└─ futures:0.1.31
└─ tokio:0.1.22
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-current-thread:0.1.7
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-fs:0.1.7
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-threadpool:0.1.18
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-tcp:0.1.4
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-threadpool:0.1.18
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-timer:0.2.13
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-udp:0.1.6
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-uds:0.2.7
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-buf:0.1.1
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-tcp:0.1.4
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-threadpool:0.1.18
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-timer:0.2.13
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ want:0.2.0
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio:0.1.22
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-current-thread:0.1.7
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-fs:0.1.7
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-threadpool:0.1.18
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-tcp:0.1.4
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-threadpool:0.1.18
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-timer:0.2.13
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-udp:0.1.6
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-uds:0.2.7
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-threadpool:0.1.18
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-timer:0.2.13
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
• tokio-core:0.1.18
└─ futures:0.1.31
└─ tokio:0.1.22
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-current-thread:0.1.7
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-fs:0.1.7
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-threadpool:0.1.18
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-tcp:0.1.4
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-threadpool:0.1.18
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-timer:0.2.13
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-udp:0.1.6
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-uds:0.2.7
└─ futures:0.1.31
└─ tokio-codec:0.1.2
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-reactor:0.1.12
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
└─ tokio-io:0.1.13
└─ futures:0.1.31
└─ tokio-sync:0.1.8
└─ futures:0.1.31
└─ tokio-timer:0.2.13
└─ futures:0.1.31
└─ tokio-executor:0.1.10
└─ futures:0.1.31
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Vulnerabilities
DepShield reports that this application's usage of rand:0.5.6 results in the following vulnerability(s):
Occurrences
rand:0.5.6 is a transitive dependency introduced by the following direct dependency(s):
• mockito:0.15.1
└─ rand:0.5.6
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Vulnerabilities
DepShield reports that this application's usage of rand_core:0.3.1 results in the following vulnerability(s):
Occurrences
rand_core:0.3.1 is a transitive dependency introduced by the following direct dependency(s):
• mockito:0.15.1
└─ rand:0.5.6
└─ rand_core:0.3.1
• reqwest:0.9.24
└─ uuid:0.7.4
└─ rand:0.6.5
└─ rand_chacha:0.1.1
└─ rand_core:0.3.1
└─ rand_hc:0.1.0
└─ rand_core:0.3.1
└─ rand_isaac:0.1.1
└─ rand_core:0.3.1
└─ rand_xorshift:0.1.1
└─ rand_core:0.3.1
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Vulnerabilities
DepShield reports that this application's usage of rand_core:0.4.2 results in the following vulnerability(s):
Occurrences
rand_core:0.4.2 is a transitive dependency introduced by the following direct dependency(s):
• mockito:0.15.1
└─ rand:0.5.6
└─ rand_core:0.3.1
└─ rand_core:0.4.2
• reqwest:0.9.24
└─ uuid:0.7.4
└─ rand:0.6.5
└─ rand_chacha:0.1.1
└─ rand_core:0.3.1
└─ rand_core:0.4.2
└─ rand_core:0.4.2
└─ rand_hc:0.1.0
└─ rand_core:0.3.1
└─ rand_core:0.4.2
└─ rand_isaac:0.1.1
└─ rand_core:0.3.1
└─ rand_core:0.4.2
└─ rand_jitter:0.1.4
└─ rand_core:0.4.2
└─ rand_os:0.1.3
└─ rand_core:0.4.2
└─ rand_pcg:0.1.2
└─ rand_core:0.4.2
└─ rand_xorshift:0.1.1
└─ rand_core:0.3.1
└─ rand_core:0.4.2
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Vulnerabilities
DepShield reports that this application's usage of lock_api:0.3.4 results in the following vulnerability(s):
Occurrences
lock_api:0.3.4 is a transitive dependency introduced by the following direct dependency(s):
• reqwest:0.9.24
└─ hyper:0.12.36
└─ tokio:0.1.22
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-udp:0.1.6
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-uds:0.2.7
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ hyper-tls:0.3.2
└─ hyper:0.12.36
└─ tokio:0.1.22
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-udp:0.1.6
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-uds:0.2.7
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio:0.1.22
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-udp:0.1.6
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-uds:0.2.7
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
• tokio-core:0.1.18
└─ tokio:0.1.22
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-tcp:0.1.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-udp:0.1.6
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-uds:0.2.7
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
└─ tokio-reactor:0.1.12
└─ parking_lot:0.9.0
└─ lock_api:0.3.4
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Use a policy report api (instead of raw report api), and use the data to build a reverse tree for components with policy violations.
Vulnerabilities
DepShield reports that this application's usage of mio:0.6.23 results in the following vulnerability(s):
Occurrences
mio:0.6.23 is a transitive dependency introduced by the following direct dependency(s):
• reqwest:0.9.24
└─ hyper:0.12.36
└─ tokio:0.1.22
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-tcp:0.1.4
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-udp:0.1.6
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-uds:0.2.7
└─ mio:0.6.23
└─ mio-uds:0.6.8
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-tcp:0.1.4
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ hyper-tls:0.3.2
└─ hyper:0.12.36
└─ tokio:0.1.22
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-tcp:0.1.4
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-udp:0.1.6
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-uds:0.2.7
└─ mio:0.6.23
└─ mio-uds:0.6.8
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-tcp:0.1.4
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio:0.1.22
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-tcp:0.1.4
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-udp:0.1.6
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-uds:0.2.7
└─ mio:0.6.23
└─ mio-uds:0.6.8
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
• tokio-core:0.1.18
└─ mio:0.6.23
└─ tokio:0.1.22
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-tcp:0.1.4
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-udp:0.1.6
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-uds:0.2.7
└─ mio:0.6.23
└─ mio-uds:0.6.8
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
└─ tokio-reactor:0.1.12
└─ mio:0.6.23
This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.
Thanks for creating an issue! Please fill out this form so we can be
sure to have all the information we need, and to minimize back and forth.
You should be able to specify an API key to use for cargo-pants
, so that someone can use their own key.
As well, you can send a basic auth header of email:password
, instead of the token, so we'd want to handle that path too.
This allows someone to essentially auth with OSSIndex.
Probably pick up an API Key from an environment variable, or something similar. For the email:password combo, build basic auth capabilities and probably pick this up from a file, maybe:
~/.cargo-pants/creds.something
Should also allow for reading credentials from environment variables.
For consistency, should follow the same naming as nancy
, eg:
export [email protected]
export OSSI_TOKEN=A4@k3@p1T0k3n
and for IQ:
export [email protected]
export OSSI_TOKEN=A4@k3@p1T0k3n
export IQ_USERNAME=nondefaultuser
export IQ_TOKEN=yourtoken
export IQ_SERVER=http://adifferentserverurl:port
In recent versions of IQ, calls to do a scan require a Content-Type
header in the html request, otherwise things go boom on the IQ side, and produce an error like the one below:
error decoding response body: expected value at line 1 column 1
Full example:
(base) MBP-DRollo5:cargo-pants bhamail$ ./target/debug/cargo-iq iq -a 'sandbox-application' -x http://localhost:8070 -l admin -k admin123 -s build -v
__
/\ \__
___ __ _ __ __ ___ _____ __ ___\ \ ,_\ ____
/'___\ /'__`\ /\`'__\/'_ `\ / __`\ _______/\ '__`\ /'__`\ /' _ `\ \ \/ /',__\
/\ \__//\ \L\.\_\ \ \//\ \L\ \/\ \L\ \/\______\ \ \L\ \/\ \L\.\_/\ \/\ \ \ \_/\__, `\
\ \____\ \__/.\_\\ \_\\ \____ \ \____/\/______/\ \ ,__/\ \__/.\_\ \_\ \_\ \__\/\____/
\/____/\/__/\/_/ \/_/ \/___L\ \/___/ \ \ \/ \/__/\/_/\/_/\/_/\/__/\/___/
/\____/ \ \_\
\_/__/ \/_/
_ __ _
|_) (_ _ ._ _. _|_ ._ _ () |_ ._ o _ ._ _| _
|_) \/ __) (_) | | (_| |_ \/ |_) (/_ (_X | | | (/_ | | (_| _>
/ / |
cargo-iq version: 0.4.5
Logging to: "/Users/bhamail/.iqserver/cargo-pants.combined.log"
Scanning only runtime dependencies for project (use --dev to include all dependencies)
🦀 Obtained package list (148)
🦀 SBOM generated
❌ Error generating Nexus IQ Server results
error decoding response body: expected value at line 1 column 1
I will try adding the Content-Type
header, and see if things get happy.
A vulnerability's title
appears to be HTML encoded.
cargo-pants
(cargo install cargo-pants
)git clone [email protected]:sonatype-nexus-community/cargo-pants.git && cd cargo-pants/
git checkout 0.1.26
)cargo-pants
on the repository (cargo pants
)lock_api
displayed as lock_api
title
appears to be the only oneA declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.