I would not be surprised if people already talked about this but I wanted to raise the the following problem.
Currently the policy of crates.io is: "Take care when publishing a crate, because a publish is permanent. The version can never be overwritten, and the code cannot be deleted." according to the publishing reference.
The problem however is this:
Let's say we have our library MyCoolLib of version 1.0.0. We have a huge project and make use of MyCoolLib a lot. The people working on MyCoolLib however have not been sitting still and release a version 2.0.0 which contains a complete re-haul of the public interface. After a while when releasing 2.4.3 they suddenly discover a big vulnerability which is contained in the code both used by 1.0.0 and 2.0.0 versions! We can basically say to people using 2.0.0 that they just have to update their packages. However people still using 1.0.0 cannot update their dependency so easily since the public interface is completely different. Since we cannot fix the vulnerability once they are deployed we are kind of stuck with a problem.
So I was wondering: Wouldn't it be a good idea to be able to re-publish earlier versions with fixes as long as the public interface doesn't change?
EDIT: I should have thought about this longer..... They can probably just release a 1.x.1 containing the fix and ask them to update to that instead right? That should fix the problem. The only problem then is how people can be made aware of vulnerable versions.
I am not sure how to close a topic, but this one can be closed by a moderator of this stream!
@DevQps To some extent, you can make people aware that the old version shouldn't be used by yanking it. In some cases this will mostly-automatically do the upgrade to the 1.0.1 version.
Thanks for your response, that sounds interesting. Can you give me a concrete example on which it will automatically do the upgrade to the 1.0.1 version?
I think he means that if you have version "1.0" in your config, it will automatically fetch "1.0.1" if "1.0.0" has been yanked
A great! I didn't know this actually existed! That really solves a lot of problems. I wonder how many people do this instead of including the exact version (including patch number). I guess this should be a best practice right? If people truly all did this, and crate maintainers published bug fixes, then it can only go wrong when a specific version is locked in Cargo.lock, or an application is already deployed somewhere. Can you actually publish crates to crates.io using this syntax? Or would it be replaced with the a version including the patch number? After all you cannot be 100 percent sure if someone changes the public interface in a patch version right?
This syntax?, it's semver. It's a best practice not to break the APIs on patch number updates but there are no guarantees. Although, it should be possible to make a (cargo-)tool for checking them
I think integrating this to crates.io would be a great step forward as well. If crates.io can just check the public API of a previous version and denies uploading a crate if the public API has been changed in a patch version bump, that would be a great step forward into using x.y as dependency versions.
Technically it could break builds, if developers would release a minor patch version that breaks certain functionality, but I think that happens less often, then people using some version x.y.z and forgetting to upgrade after a big bug / vulnerability has been patched.
@Shnatsel Maybe we can create an issue for this? I am not really sure how hard it would be to actually implement this for crates.io however. But I think it would be a great addition.
It does, however, require that there is a 1.0.1 patched version to update to; ie that the crate maintainer does back-port their bugfix.
@Daniel Carosone You mean that crates.io already does this? Or do you mean that in order for this to work people should back-port their bug-fix?
yeah, there needs to be a back-ported fix release, in order for users to upgrade to it. Seems obvious, but it might not be a valid assumption. There's no mandatory or consistent maintenance policy for crates.