I have accidentally published my private crate to crates.io. How do I delete it? I checked the documentation but it seems like there is no way to delete a published crate.
Prevention
To avoid this situation in the future, ensure that you include:
[package]
# ...
publish = false
in your crate's Cargo.toml. See documentation.
Mitigation
Immediately yank the crate using:
cargo yank --vers <your-version>
This will prevent any other crate to accidentally start depending on it.
If any secret was accidentally published (passwords, keys, ...), consider them no longer secret and take appropriate steps to replace them with fresh ones.
Removal
Contact help at crates.io and explain the situation, asking for removal.
If your explanation is well-founded, and the crate has not been downloaded and thus depended on, they have no reason to refuse helping.
Please be patient; once the crate is yanked nobody can start depending on it anyway, so there should be little time pressure. Give the team a few days to actually perform the removal.
If the matter is time sensitive for some reason, you can hop on IRC or Discourse and grab the attention of someone with the powers to perform the removal. Ask and you'll be directed to such a person.
The Crates.io policies say this under Removal:
We will do what the law requires us to do, and address flagrant violations of the Rust Code of Conduct. […] Crates.io will respect Mozilla Legal’s decisions with regards to content that is hosted.
I suggest to send mail to help#crates.io as a start, and if they prove uncooperative, escalate to Mozilla Legal. Only as a last resort, add a deliberate Code of Conduct violation to trigger the removal.
EDIT I agree that this is not a desirable situation, so I submitted a pull request with a proposed policy change.
You cannot delete a crate once it is published. However, you can yank it to mark your crate as not usable: basically, nobody will use it, and no or few people will want to see the content. This policy allows to forbid the arbitrary breakage of other crates that use your package as a dependency.
If you have code or information in this crate that you do not want to be public, refer to the other answer.
Related
When I document my project by 'cargo doc' then it can happen that the name of my own project shadows a dependend crate which is then invisible.
So I do not see that a crate with the same name exists and this crate then keeps undocumented.
How can I tackle this problem?
The best workaround is to just avoid this situation from the beginning. Just make sure you're not shadowing any public crates names. You can check on crates.io if your desired name is available, if it's not I strongly recommend you choose a different name since if you ever want to publish it you'd have to rename it anyways.
I want to extract all nightly features used by a crate for some research purposes.
Just to be clear, "nightly features" means codes like #![feature(...)]", but not crate provided optional features.
I tried using regex, and it works, but not accurate enough. cfg defined features may not be detected: #![cfg_attr(target_os = "macos", feature(...))].
So I turn to rustc compiler, I wish to modify some source code and print out what features crate uses. Now I'm still trying to find out how rustc deals with nightly features.
I hope someone can give me some tips and help about the process of rustc dealing with nightly features. I'm almost lost in codes.
Access to enabled features is done via rustc_session::Session::features. You can add code after they are set in rustc_interface, or look at how they're computed.
If you are at a later stage, you probably have access to the Session of the compiled crate. For example, TyCtxt has a sess() method (but also a features() method for direct access using the query system), and InferCtxt has a tcx member to access the TyCtxt.
The Rust compiler checks for lots of security issues (e.g. the borrow checker, ownership rules, etc.) and prevents insecure code from even compiling. This is amazing.
However, what if hackers who want to publish malware compile the code using their own manipulated compilers which do not check for any of those rules anymore?
There will be lots of Rust crates in repositories soon and developers are relying on their code's security just because of the Rust compiler.
The problem of users getting shady binaries from untrusted sources is completely orthogonal to Rust's promise of memory and thread safety.
Rust aims to make it harder to accidentally write buggy code that could be exploited by a hacker, not to make it impossible to write malicious code.
All crates from crates.io are compiled again when you use them, so it is impossible for a crate author to introduce memory unsafety that way.
Of course, if a crate uses unsafe code, then it's up to you to be comfortable with what the author has done.
Let's break this down:
We know that the Rust compiler will check for lots of security issues (e.g. Borrow check, Ownership rules, etc) and prevent insecure code even to be compiled. This is amazing.
Yes, this is true. The Rust compiler will enforce type and memory safety.
However, what if hackers who want to publish sort of malsoftwares, compile the codes using their own version of manipulated compilers which do not check for any of those rules anymore?
If you download a crate that was published on crates.io, the crate will be recompiled locally. It is true that downloaded crates may use unsafe code that avoids some memory safety enforcement.
In the case of downloading a binary directly off the internet (not through crates.io), you cannot be sure that what you are downloading is what is says it is. In fact, a file marked as a Rust library may in fact be a virus written in assembly. This problem has nothing to do with Rust, or any other language.
There will be lots of Rust crates and libs on the repositories soon and developers are relying on their code's security just because of Rust compiler.
This not true. Developers may be relying on the type and memory safety of their code that is enforced by the compiler. However, just because the compiler enforces safety within you code does not mean that you it will stop viruses or malware from infecting your device. Anything that you download off the internet can potentially harm your device, regardless of the language.
I added one dependency to my project which added another and another - in the end, I got the crate pelite. This crate has a "blob" file which was marked by Windows as "Trojan:Win32/Fuery.B!cl"
I assumed that this was a false positive, but it wasn't shown as a "maybe/possible" trojan. I found the crate on GitHub and downloaded the "blob" file from GitHub and it is ok. If I download it from crates.io (either via Cargo or manually) then I get the trojan warning.
My problem is that cargo run downloaded and ran it as the antivirus couldn't stop it or delete the file.
Your first step should be to establish that the malware was not run on your system. Nothing inside of Cargo or Rust will run that specific file automatically, but the crate might contain a build script
The next step is to ascertain if it actually is malware. pelite has an issue where this has been raised:
Ugh this dumb issue, it's a false positive which I already tried to make go away once.
That file contains like 200 PE samples for testing pelite against. These are fairly unusual samples because I wanted to see how pelite would fare and due to their unusual nature tend to get picked up by anti virus.
If you trust the author that it's not really an issue, then there's nothing else to do.
If the author isn't aware of the issue, you can try reaching out to them, following any security contact information they might have (relatively rare for most crates) or opening an issue.
If you don't trust the crate owner or they are unreachable, your final step should be to contact the Rust Security Team via email. Be complete and thorough about the issue and provide as much information as you can.
In my personal opinion, the particular warning you are asking about is a false positive and I would not worry about it. Running an online virus scanner (which I don't know the quality of) reports it as a large number of possible things, in line with what the author said about being a large number of samples.
I am looking for a Rust library to parse dates and I found the documentation for time which looks official.
I wanted to report a bug so I went to the Crates.io page, which led me to the Github repository which sneakily redirected to the rust-deprecated Github account.
Is this library deprecated or not? How can I find out? There's no indication in the documentation or the code.
One problem here is that libraries often become deprecated because the maintainer doesn't have time. So the person who has the power to say "deprecated" also isn't in the position to do it.
The next release of Rust (1.9) will contain a "deprecated" attribute, which would allow someone to mark any part of an API as deprecated, and I guess it could be applied to a whole crate too.
That said, for "time", "deprecated" has a very specific meaning: it's a crate that was almost official, but is not any more, and has not had a new maintainer yet. If anyone wants to take over maintenance, they can request it, and it will be given to them. This only applies to crates that are in the rust-lang-nursery organization, and even that is a bit of history. In the future, I doubt many crates will end up "deprecated" in this way.