Path to v1.0?

[benesch]

Hi @marshallpierce! First of all, thanks for making such a foundational piece of the Rust ecosystem!

I wanted to ask if you had a plan for releasing a v1.0. As of this issue there are 816 crates that depend on base64: https://crates.io/crates/base64/reverse_dependencies. Many of those crates are themselves foundational, and so base64 appears in the transitive dependency set many layers deep. That means that every minor release of base64 causes a pretty massive cascade of dependencies that need to be themselves released with the updated version.

I know releasing v1.0 places a backwards compatibility burden on you, but wondered if you had a timeline, or work items we could help out with!

[marshallpierce]

Good question. At this point, there are 2 things I would like to see before 1.0:

• Let people easily provide their own charsets (It's hard to use our own character set tables. How about making encode and decode modules public? #87). Making config be a trait and making encoding/decoding generic over that trait is likely a good path here.
• Support SIMD implementations via yet another trait and generic parameter. Probably all that needs to be done there is the "fast loop": pull the current one out into a Scalar implementation, and add fun stuff from https://lemire.me/blog/2018/01/17/ridiculously-fast-base64-encoding-and-decoding/.

Both of these were explored in #91, but it was just too big and invasive for me to review in a timely fashion, so it got stale.

[Sytten]

Any progress?

[marshallpierce]

I've got PRs waiting for me on AVX2 and constant-time implementations (almost ready). Real life just needs to give me a break so I have time to give to them. :)

[bstrie]

Note that the RustCrypto project has their own constant-time base64 crate (https://crates.io/crates/base64ct), so if this crate were to gain constant-time support then perhaps they would be willing to deprecate their crate and instead lend a hand in the maintenance of this one.

[marshallpierce]

Yep, I hope we can find a way to offer everything RustCrypto needs.

I'm currently working on #182. After that, getting #170 and a constant time impl in seems like a good point to call 1.0.

[jjant]

Hey @marshallpierce I was wondering if there's any news/help needed for #181/#182? Thank you!

[marshallpierce]

I managed to get about 90% of the way to an implementation in master...mp/invalid-padding, and then got too busy in real life again to finish it. I'll probably have time during the holiday season to get it over the line (which is basically fixing the last few tests and inspecting my design decisions with fresh eyes).

If you have time to help, probably the most accessible task for someone other than me to do relatively quickly would be to assess the API changes, docs, etc in there: are they sufficiently clear? Is it easy to pick the "right" one for hypothetical use cases?

[ia0]

FYI for those looking for a stable crate for base64, base32, hexadecimal, and other standard or custom data encodings: The data-encoding crate has been stable and correct since its first release 8 years ago (and v2 since 6 years).

[BenjaminBrienen]

@marshallpierce

Would you reconsider releasing a v1.0?

[marshallpierce]

Let's wait until #231 is done, since that will (minorly) break backwards compatibility by requiring BufRead instead of Read. I'm also working on support for custom padding tokens to address #276.

The other not currently in progress thing that maybe we should address for 1.0 is #148. Since the doc updates in stdlib have landed, maybe we should change behavior to match.

Otherwise, I can't think of anything that's come up that would affect API usage or API contracts.

[bushrat011899]

Worth noting that as far as I can tell, std is only used for std::error::Error with a low MSRV, std::io, and feature detection (is_x86_feature_detected! and is_aarch64_feature_detected!). With an increased MSRV, std::error::Error can be imported from core (as already noted in #298), and std::io is currently available from alloc in nightly. Might be worth waiting for alloc::io to be stable to justify a much higher MSRV for 1.0 (or as previously mentioned, autoconf/build.rs).

[BenjaminBrienen]

Leave it to bushrat to have an eye out for no_std opportunities ;)

I like that idea.

[marshallpierce]

Given my once-in-a-great-while OSS availability, alloc::io may well have landed by the time I've finished off the other 1.0 tasks. ;)