Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

Optimise human readable output for narrow terminals #85

Closed
idkw opened this issue Dec 19, 2022 · 6 comments · Fixed by #87 or #889
Closed

Optimise human readable output for narrow terminals #85

idkw opened this issue Dec 19, 2022 · 6 comments · Fixed by #87 or #889
Assignees
@michaelkedar @another-rex
Labels
bug Something isn't working

Comments

@idkw
Copy link

idkw commented Dec 19, 2022 •
edited
Loading

When using the default textual output and the SOURCE path is long enough, the output is truncated.

All lines end with a ≈ and are truncated which make the output unusable because it misses the OSV URL entirely.

╭────────────────────────────────────────────────────┬───────────┬─────────────────────────┬───────────────────────────────────┬───────────────────────────── ≈
│ SOURCE                                             │ ECOSYSTEM │ AFFECTED PACKAGE        │ VERSION                           │ OSV URL (ID IN BOLD)         ≈
├────────────────────────────────────────────────────┼───────────┼─────────────────────────┼───────────────────────────────────┼───────────────────────────── ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│ xxxxx/xxxxx/node_modules/package-lock.json         │ npm       │ lodash                  │ 4.17.4                            │ https://osv.dev/vulnerabilit ≈
│

I know about the JSON output, but I'd like to have an untruncated textual output too because it is more readable.
@idkw idkw changed the title Output is truncated Output is truncated when SOURCE path is too long Dec 19, 2022
@another-rex another-rex added the bug Something isn't working label Dec 19, 2022
@another-rex another-rex mentioned this issue Dec 19, 2022
Merged
@oliverchang
Copy link
Collaborator

oliverchang commented Dec 19, 2022 •
edited
Loading

Re-opening as #87 was a partial fix/mitigation.

@oliverchang oliverchang reopened this Dec 19, 2022
@oliverchang
Copy link
Collaborator

Thanks for trying osv-scanner and opening this issue!

We've made some changes to mitigate this, and released https://github.com/google/osv-scanner/releases/tag/v1.0.2 which includes:

  • Moving the source column to be the last column
  • Better support for piping into less -S, which lets you horizontally scroll on narrow terminals.
  • Reducing the width of some column headers

Most of our team is out for the rest of the year, but once we're back early next year we'll work on improving this further!

@oliverchang oliverchang changed the title Output is truncated when SOURCE path is too long Optimise human readable output for narrow terminals Dec 20, 2022
@idkw
Copy link
Author

idkw commented Dec 20, 2022

Thanks !

@G-Rath
Copy link
Collaborator

G-Rath commented Dec 21, 2022

@oliverchang @another-rex this could be a good time to talk about supporting the output style of osv-detector as an alternative because that should be much better suited for narrow terminals:

Loaded the following OSV databases:
  Go (1003 vulnerabilities, including withdrawn - last updated Wed, 21 Dec 2022 18:22:46 GMT)

go.mod: found 8 packages
  Using config at .osv-detector.yaml (1 ignore)
  Using db Go (1003 vulnerabilities, including withdrawn - last updated Wed, 21 Dec 2022 18:22:46 GMT)

  golang.org/x/sys@0.0.0-20210630005230-0f9fa26af87c is affected by the following vulnerabilities:
    GO-2022-0493: When called with a non-zero flags parameter, the Faccessat function can...

  1 known vulnerability found in go.mod

what do you think?

@another-rex
Copy link
Collaborator

I do like how that looks, we can add a flag like e.g. --output-type=<table|text|json> for specifying what output type will be, though we still need to keep the --json flag for compatibility.

@deftdawg deftdawg mentioned this issue Jan 21, 2023
Merged
@G-Rath G-Rath mentioned this issue Jan 21, 2023
Merged
@michaelkedar michaelkedar mentioned this issue Feb 3, 2023
Closed
@Dentrax Dentrax mentioned this issue Feb 17, 2023
Closed
9 tasks
@oliverchang
Copy link
Collaborator

I believe there's no more remaining work here? (@another-rex please reopen if I'm wrong).

@oliverchang oliverchang mentioned this issue Apr 27, 2023
Closed
@G-Rath G-Rath mentioned this issue Mar 26, 2024
Merged
hogo6002 pushed a commit that referenced this issue Jul 26, 2024
@G-Rath
feat: add "vertical" output format (#889)
42514fc 
This adds a new "vertical" output format that is designed for humans and
based on the output of `osv-detector`, which effectively aims to group
the output relating to each entity being scanned in vertical slices:

<img width="898" alt="image"
src="https://github.com/google/osv-scanner/assets/3151613/61297153-5c22-43a4-a78e-e07ce648142a">

Unfortunately I think it suffers significantly due to the assumptions
made by the rest of the codebase for outputting that made sense when the
final output was a table i.e. we dump a lot of information as we go
about scanning, config files, vulnerability filtering, and so on that
really should be grouped but currently cannot because they're all
outputted at different stages - I think a way to address that could be
using some sort of event-emitter type pattern so that the reporters
could be responsible for deciding what they actually do (e.g.
`r.Emit("filtered-vulnerability", ...)` and then most reporters could
choose to just print immediately, and ones like "vertical" could choose
to add it to an internal struct), but I think that'll involve a lot more
work; for now I'm just going to ignore the pre-results output.

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

@michaelkedar michaelkedar

@another-rex another-rex

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
5 participants
@oliverchang @G-Rath @idkw @michaelkedar @another-rex