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.

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

Spin is no longer actively maintained (RUSTSEC-2019-0031) #22

Closed
gendx opened this issue Feb 6, 2020 · 4 comments · Fixed by #23
Closed

Spin is no longer actively maintained (RUSTSEC-2019-0031) #22

gendx opened this issue Feb 6, 2020 · 4 comments · Fixed by #23

Comments

@gendx
Copy link

gendx commented Feb 6, 2020

Running cargo audit on https://github.com/google/OpenSK reveals that linked_list_allocator depends on spin, which is no longer actively maintained (advisory RUSTSEC-2019-0031).

Crate:  spin
Title:  spin is no longer actively maintained
Date:   2019-11-21
URL:    https://rustsec.org/advisories/RUSTSEC-2019-0031
Dependency tree: 
spin 0.5.2
└── linked_list_allocator 0.6.6
    └── libtock 0.1.0

Full Travis-CI log: https://travis-ci.org/google/OpenSK/builds/646900743.

It seems that spin is an optional dependency and active when the use_spin feature is enabled (which is by default).

The advisory suggests to migrate to https://crates.io/crates/lock_api or https://crates.io/crates/conquer-once (according to the advisory, both should support no_std).

@phil-opp
Copy link
Member

Thanks for reporting! From a quick look at the two recommended libraries, it seems like only lock_api is an alternative in our case (conquer-once does not provide a spinlock type). However, the lock_api crate only provides an API and requires users to create a spinlock type themselves. Copy&pasting code and managing it ourselves is not really better than using a dependency that is no longer actively maintained in my opinion.

I opened Amanieu/parking_lot#214 to propose the addition of a Spinlock type to lock_api. Depending on the outcome, it might be a good idea to create a new spinlock crate with this type ourselves.

@phil-opp
Copy link
Member

Update: I just created a small spinning_top crate that provides a simple spinlock implementation on top of lock_api: https://docs.rs/spinning_top/0.1.0/spinning_top/. Feedback an reviews are appreciated! If everything looks good, I think we can migrate the linked-list-allocator crate to it.

@gendx
Copy link
Author

gendx commented Feb 17, 2020

Thanks @phil-opp! I filed an issue on the RustSec advisory repo to mention this new crate, but maybe you want to wait before advertising it directly on the RUSTSEC-2019-0031 advisory?

In the end, it would all boil down to creating a pull-request to mention spinning_top in https://github.com/RustSec/advisory-db/blob/master/crates/spin/RUSTSEC-2019-0031.toml.

@phil-opp
Copy link
Member

I can't guarantee for its correctness of course, but I think it's ready for people to try it. I opened rust-osdev/spinning_top#2 to ask for reviews and I just got an approving review from the author of lock_api, so there don't seem to be any obvious mistakes.

So feel free to add it to the RustSec advisory repo if you like!

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

Successfully merging a pull request may close this issue.

2 participants