Stream: wg-secure-code

Topic: patching-previous-versions

DevQps (Mar 16 2019 at 21:21, on Zulip):

Hello everyone,

I would not be surprised if people already talked about this but I wanted to raise the the following problem.

Currently the policy of 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?

DevQps (Mar 16 2019 at 21:24, on Zulip):

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!

briansmith (Mar 16 2019 at 21:27, on Zulip):

@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.

DevQps (Mar 16 2019 at 21:29, on Zulip):

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?

snf (Mar 16 2019 at 21:44, on Zulip):

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

DevQps (Mar 16 2019 at 21:50, on Zulip):

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 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?

snf (Mar 16 2019 at 22:08, on Zulip):

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

DevQps (Mar 17 2019 at 09:12, on Zulip):

I think integrating this to would be a great step forward as well. If 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 (Mar 17 2019 at 13:21, on Zulip):

The tool actually exists:
But yes, I was very much surprised when I found that uploads violating semver are not rejected by

DevQps (Mar 17 2019 at 18:23, on Zulip):

@Shnatsel Maybe we can create an issue for this? I am not really sure how hard it would be to actually implement this for however. But I think it would be a great addition.

Daniel Carosone (Mar 19 2019 at 03:16, on Zulip):

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.

DevQps (Mar 19 2019 at 06:25, on Zulip):

@Daniel Carosone You mean that already does this? Or do you mean that in order for this to work people should back-port their bug-fix?

Daniel Carosone (Mar 19 2019 at 08:05, on Zulip):

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.

Last update: Apr 04 2020 at 04:10UTC