Why have you yanked (not even very) old versions without documenting it?

[ghost]

Porting an existing application to a new system, I came across some very unexpected deadlock/livelock behaviour that looks suspiciously similar to #2047 and #2316 using tokio and FuturesUnordered.

Since the code itself has changed very minimally to the last time I built it, my first thought was to pull back dependencies to the exact versions used during the previous builds (in my case, 0.3.8 of futures). But I was thwarted by what appears to be a lot of yanking of previous versions.

I can't find any documentation as to why these are yanked? Of course, I can probably just pull the code from the repo at the desired tag, but to me a yank suggest some sort of known security issue I should be aware of? If they weren't yanked due to security issues, why yank at all?

--

Of course, if the yanks were documented and I've simply missed it, I do apologise.

[taiki-e]

Yanking is basically due to a security bug, a soundness bug, or a regression.
Please read the release notes for the oldest unyanked semver compatible version. In this case, 0.3.11.

https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md#0311---2021-01-14

Fixed heap buffer overflow in AsyncReadExt::{read_to_end, read_to_string} (#2314)

I thought "fixed heap buffer overflow" was sufficient to indicate that it fixed a soundness bug that could cause security issues, but if you or someone else thinks it's not sufficient, we can add a more explicit explanation about them being yanked.

---

Porting an existing application to a new system, I came across some very unexpected deadlock/livelock behaviour that looks suspiciously similar to #2047 and #2316 using tokio and FuturesUnordered.

It's not clear to me what happened since there is no specific information, but you may be able to work around it by using unconstrained if the problem is related to compatibility with tokio's cooperative scheduling.

[ghost]

Thanks for the info!

I thought "fixed heap buffer overflow" was sufficient to indicate that it fixed a soundness bug that could cause security issues, but if you or someone else thinks it's not sufficient, we can add a more explicit explanation about them being yanked.

Indeed, I would agree that "heap buffer overflow" (with link to issue) is enough to identify it as a security bug. What I don't agree with is this being easy to find for someone like me who just goes "hey, why was my version yanked?" quite a while in the future. Adding "therefore yanked versions X through Y" would have at least had it turn up in searches.

---

It's not clear to me what happened since there is no specific information, but you may be able to work around it by using unconstrained if the problem is related to compatibility with tokio's cooperative scheduling.

That's a great tip, thanks. I deliberately didn't provide detail, since I wanted to keep this issue single-topic. If/when I have time to investigate further and see if it is a futures-rs problem, I'll open a separate issue.

[taiki-e]

Added description about yanking to changelog in #2537.

Also, the FuturesUnordered and tokio issue that you encountered was likely fixed in 0.3.19 (#2527).