Skip to content

[Build] RUSTSEC-2020-0071: Potential segfault in the time crate #325

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.

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

Closed
c0dearm opened this issue Jun 24, 2022 · 5 comments · Fixed by #326
Closed

[Build] RUSTSEC-2020-0071: Potential segfault in the time crate #325

c0dearm opened this issue Jun 24, 2022 · 5 comments · Fixed by #326
Assignees
Labels

Comments

@c0dearm
Copy link
Contributor

c0dearm commented Jun 24, 2022

Description

arrayfire-rust depends on the mnist package that in turn depends on the time crate.

The following security advisory was raised tonight regarding the time crate: c0dearm/mushin#16

I think there are a few things to do here:

  • Upgrade the mnist package so that the security vulnerability is not there anymore.
  • Set up a GitHub workflow to check for package vulnerabilities (like it is done in the mushin project)
  • Is mnist really a required dependency? Would it be possible to have it only as a dev dependency or in a Cargo feature flag?
@9prady9
Copy link
Member

9prady9 commented Jun 25, 2022

@c0dearm Firstly, thank you for bringing this to my attention.

I should have caught this earlier, this should be in dev-dependencies of cargo manifest indeed. Must have slipped through. Sorry about that. However, rest assured that crate from crates.io won't have it as dependency and thus users of arrayfire crate are safe. I have addressed it here already #326

A git hub action to check for vulnerabilities would be definitely useful in general. I think it should run on a PR only if Cargo file is changed. Otherwise, running it on master branch for push event would suffice.

@c0dearm
Copy link
Contributor Author

c0dearm commented Jun 25, 2022

Hi! It can be just scheduled to run once a day or so.

Even if there's no update in the Cargo.lock a new vulnerability might be discovered in one of the package versions.

@9prady9
Copy link
Member

9prady9 commented Jun 25, 2022

@c0dearm would you be interested in submitting a PR for this job ? I have created an issue for this #327

@c0dearm
Copy link
Contributor Author

c0dearm commented Jun 25, 2022

Sure! I will try to find some time between today and tomorrow 🙂

@9prady9
Copy link
Member

9prady9 commented Jun 25, 2022

Sure! I will try to find some time between today and tomorrow slightly_smiling_face

thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants