Bincode dependency now unmaintained

[ratmice]

The README for bincode has marked the crate as unmaintained
as of a day or so ago. There was a recent mistaken suspicion of a supply chain attack which appears to be unfounded. But I don't know of any urgent issues like bugs or anything, besides the maintenance status (specifically no security issues I know of that need to be taken care of immediately).

There was one issue here which downgraded imbl due to the msrv 1.85 of the latest bincode.
here mattwparas/helix#72
release. I felt like the msrv bump was worthwhile given the benefits of the latest bincode releases (when one can benefit from the serde optionality as was discussed in #134 ).

It isn't clear to me whether any of the alternative crates listed in the readme really fit the same niche.

[jneem]

Thanks for calling this out. Given that it's an off-by-default optional feature, this doesn't seem very urgent. @PieterPenninckx, what are your thoughts? Have you switched to any bincode alternative?

[PieterPenninckx]

Hi @jneem , I agree this doesn't seem very urgent. The status is not very clear. The README on crates.io states that it's "unmaintaned" and "no further releases will be published on crates.io", but the readme on sourcehut states that "Version 1.3.3 is considered a complete version of bincode that is not in need of any updates. Updates will only be pushed to the in the unlikely event of CVEs." (Note that the version we are depending on is not version 1.3.3, but version 2.0.1.)

Concerning alternatives: wincode seems to be the closest, but also depends on syn (so doesn't have the same benefits as bincode). I haven't switched to any bincode alternative and I don't know what I will do. (Except maybe to include a note in the README of all my projects stating that the correct way to report a potential supply chain attack is with the "report" button on crates.io.)

I'm also not sure whether the MSRV of a project has to be in line with the MSRV of its optional dependencies (especially in this case since you would only use imbl with the bincode feature when you are also depending on bincode in another way).

[ratmice]

Yeah, I feel like the 1.3.x and 2.x maintenance requirements are completely different,
in particular 1.3.x builds on the serde traits, while 2.x builds on it's own traits.

This causes a completely different dynamic for future std changes, for instance I could imagine
a situation where (for instance) something such as the Pattern types RFC is stabilized, people
would need to implement the Encode/Decode traits for the new types. Because of orphan rules at that time to do that you'd basically need to fork.

This isn't the case with 1.3.x where to get the same effect you'd also need the serde traits and derive macros to go unmaintained and/or break compatibility (not that depending on an unmaintained crate is great in that case either).

It just seems to me like that with the 2.x traits and orphan rules it isn't enough for the code to be solid implementation of the serde traits which if those stay semver compatible will continue to work.
There are now trait implementations and each additional derive of those traits is only going to make ripping off the band-aid when the times eventually comes a bit more painful.

Anyhow, I'm hit by bincode 2.x issues not through imbl, but via other crates, I feel like the traits are what cause me the most problems there since I didn't export the dependency as a module like crate::bincode, so for us even switching to a different copy of the same trait is going to impose some semver problems.

Edit: One more thing I didn't see in the readme, was that they stated they will not transfer ownership of the crate to new maintainers. From the readme it states something about crates.io itself transferring ownership. Thus I don't have much hope that these trait issues can be resolved that way.

[nmccarty]

Former emergency keyholder for bincode here.

First of all, thank you all for having a thought out and level headed approach to this.

Secondly, I just wanted to clarify the maintenance status:

Edit: One more thing I didn't see in the readme, was that they stated they will not transfer ownership of the crate to new maintainers. From the readme it states something about crates.io itself transferring ownership. Thus I don't have much hope that these trait issues can be resolved that way.

There were a few escalating steps taken in short order in response to escalating harassment from various sources both in the original reddit thread and without it, things were happening so fast it was hard to stay on top of the messaging, but we wound up taking a more final option than we would have liked.

We would have liked to turn the crates.io package over to the community through a crates.io-or-other-community-entity lead package abandonment process, like what many other programming language communities have, but the rust ecosystem unfortunately has nothing of the sort currently.

No trustworthy candidates to hand off the project to were available at the time of the incident, and none of us have the bandwidth or desire to go track one down fresh and vet them at the moment, so the only option we were left with to ensure that nobody breaks into our accounts and pushes a malicious version in our absence was to leave the crates.io entry for bincode effectively ownerless by having the owner of the project remove all the other owners from the crates.io entry and then deleting her own github account. At this point in time, the only way anyone is pushing a new bincode release if if there is a major crates.io exploit, or if crates.io implements a redemption process for unmaintained packages.

I would very much like, for the health of the community in general, for rust to eventually introduce a package transfer policy, like what many other programming language communities have, but until such time that crates.io adopts such a policy, it will not be possible for bincode to have any future legitimate releases. Sorry for the headache.

[PieterPenninckx]

@nmccarty , thank you for clarifying. I now better understand the perceived difference in the README's on crates.io and on sourcehut. No reason to apologize. I understand and I'm grateful for the work that went into bincode.

@jneem , for imbl, I would mark all code referring to bincode as deprecated (where possible) and remove it when the 7.x series of imbl is released. If you want, I can create a PR when I find the time for that. Concerning the MSRV: in my opinion that can be lowered again (see my previous comment), but I'm not the maintainer. As for my own usage of bincode: the wincode system doesn't suit my needs, I'm probably going to "roll my own dice".

[ratmice]

In the dependency where I use we were never fully able to excise syn, but it has occurred to me one route via which we could make use to make syn optional, I've brought that up with the maintainers of that package. But I think if I could manage to actually benefit from the syn I wouldn't mind collaborating on a more passively maintained continuation/fork of the current bincode 2.x codebase?