Archive this repo?

[workingjubilee]

This code isn't really heavily maintained, it's volatile and liable to be unsound (see https://github.com/servo/rust-stb-image/issues/103 for instance), is there a reason to not just archive this repo and have done with it?

[workingjubilee]

cc @MarijnS95 in https://github.com/servo/rust-stb-image/pull/105 you indicated you were using it and alluded to doing more maintenance to this crate. Could you explain your use case a bit more? Does this crate offer significant features that e.g. image does not?

[MarijnS95]

"We" as in "collectively the open source community" should put more effort in maintaining this crate.

If I remember correctly it was - maybe still is - much faster at loading images.

The stb_image_rust crate you linked, in typical Rust NIH fashion (🙁), looks to have been created as quickly as it got abandoned :/

[mbrubeck]

As a maintainer, I would prefer to keep this repo writeable for now so we can apply updates and fixes to benefit the few people still using this library. However, I do think that we should do what we can to encourage most people not to use this library. Perhaps that should include a RustSec advisory so tools like cargo-audit will complain. Documentation pointing to alternatives is definitely a good idea.

The upstream C library always has many open security bugs, and as a matter of policy its maintainers do not intend the code to be usable with untrusted input or in any other security-sensitive context. Most Rust projects expect rather different standards regarding security and undefined behavior, and should be using the pure Rust image libraries instead. Most contributions should be (and are) going toward improving those libraries, including making sure their performance is competitive with stb_image.

[workingjubilee]

@MarijnS95

The stb_image_rust crate you linked, in typical Rust NIH fashion (🙁), looks to have been created as quickly as it got abandoned :/

yeah I unlinked it as soon as I looked a bit more closely because yeah that's 🫠

If I remember correctly it was - maybe still is - much faster at loading images.

Ah, something to benchmark! cool, that can be done.

@mbrubeck:

As a maintainer, I would prefer to keep this repo writeable for now so we can apply updates and fixes to benefit the few people still using this library. However, I do think that we should do what we can to encourage most people not to use this library. Perhaps that should include a RustSec advisory so tools like cargo-audit will complain. Documentation pointing to alternatives is definitely a good idea.

aha! that makes sense then.

[workingjubilee]

@mbrubeck Thank you. I opened issues for the two action items that seem directly associated with this crate, to catch up with later, and obviously we can table this one for now.