Cargo audit multiple findings

[ghost]

it appears cargo audit finds a number of issues with qsv. is it possible these will be considered for resolution? the tough one may be chrono which doesnt seem maintained, but using time directly seems to work for other crates.

Crate:         chrono
Version:       0.4.19
Title:         Potential segfault in `localtime_r` invocations
Date:          2020-11-10
ID:            RUSTSEC-2020-0159
URL:           https://rustsec.org/advisories/RUSTSEC-2020-0159
Solution:      No safe upgrade is available!
Dependency tree:
chrono 0.4.19
├── qsv 0.32.0
└── dateparser 0.1.6
    └── qsv 0.32.0

Crate:         rustc-serialize
Version:       0.3.24
Title:         Stack overflow in rustc_serialize when parsing deeply nested JSON
Date:          2022-01-01
ID:            RUSTSEC-2022-0004
URL:           https://rustsec.org/advisories/RUSTSEC-2022-0004
Solution:      No safe upgrade is available!
Dependency tree:
rustc-serialize 0.3.24
├── reverse_geocoder 2.0.1
│   └── qsv 0.32.0
└── quick-csv 0.1.6
    └── reverse_geocoder 2.0.1

Crate:         time
Version:       0.1.43
Title:         Potential segfault in the time crate
Date:          2020-11-18
ID:            RUSTSEC-2020-0071
URL:           https://rustsec.org/advisories/RUSTSEC-2020-0071
Solution:      Upgrade to >=0.2.23
Dependency tree:
time 0.1.43

Crate:         tokio
Version:       0.2.25
Title:         Data race when sending and receiving after closing a `oneshot` channel
Date:          2021-11-16
ID:            RUSTSEC-2021-0124
URL:           https://rustsec.org/advisories/RUSTSEC-2021-0124
Solution:      Upgrade to >=1.8.4, <1.9.0 OR >=1.13.1
Dependency tree:
tokio 0.2.25

Crate:         net2
Version:       0.2.37
Warning:       unmaintained
Title:         `net2` crate has been deprecated; use `socket2` instead
Date:          2020-05-01
ID:            RUSTSEC-2020-0016
URL:           https://rustsec.org/advisories/RUSTSEC-2020-0016
Dependency tree:
net2 0.2.37
├── miow 0.2.2
└── mio 0.6.23

Crate:         stdweb
Version:       0.4.20
Warning:       unmaintained
Title:         stdweb is unmaintained
Date:          2020-05-04
ID:            RUSTSEC-2020-0056
URL:           https://rustsec.org/advisories/RUSTSEC-2020-0056
Dependency tree:
stdweb 0.4.20
└── time 0.2.27

error: 4 vulnerabilities found!
warning: 2 allowed warnings found

[jqnatividad]

Hi @portno12 ,
The chrono dependency is indeed a tough one, but the risk is minimal in qsv as we only use chrono in the dateparser crate which we use to recognize date formats in apply datefmt and stats. We do not use it in a way that involves fetching localtime_r.

As for rustc-serialize, the exposure is also minimal, as its used in the reverse-geocoder crate to deserialize a CSV file, not a JSON file. (I opened an issue regardless - gx0r/rrgeo#7)

time 0.1.43 is also used by the zip crate, which in turn, was because of qsv using self-update to download the latest zipped qsv binaries from GitHub. A fix has already been merged in zip master, and it'll be automatically applied once its released (zip-rs/zip-old#232). If its not merged in time for the next release, I'll just switch to tar files to eliminate the zip dependency.

As for tokio 0.2.25, net2 and stdweb, they're all just dev-dependencies for testing the fetch command, so they're not in the release binary.

[ghost]

@jqnatividad thanks for the info. would it be possible, or would you accept a pr, to still make any applicable changes to lower the number of findings? regarding chrono other crates have been moving to time itself, does it provide the same functionality for this?

[jqnatividad]

@portno12 yes. PRs are welcome!

As for chrono, we only use it because of dateparser for the apply datefmt operation:
https://github.com/jqnatividad/qsv/blob/42bde80107a938b7395284fe802d90922255f964/src/cmd/apply.rs#L427-L437

And in stats to infer if a column is a date column:
https://github.com/jqnatividad/qsv/blob/42bde80107a938b7395284fe802d90922255f964/src/cmd/stats.rs#L540-L578

I'm not that familiar with time to know if it has the same date parsing functionality that dateparser leveraged. If anything, you may want to check if dateparser can be switched to time or use an alternative crate to parse dates as it uses chrono extensively.

[github-actions]

Stale issue message

[ghost]

@jqnatividad i havent had time to look further into this. any progress on the projects side?

[jqnatividad]

@portno12 All that remains now is the chrono vulnerability, and there's some interesting activity on that front, so I'll just wait for them to fix it upstream...

[jqnatividad]

all cargo audit findings are now resolved with the new qsv-dateparser.