Change base64 crate to simple-base64 crate

[drogus]

Description of Changes

Standard base64 encode/decode functions have been deprecated and it's clear that the maintainer doesn't care about ergonomics of using the crate[1], so I've forked the crate to be able to get back to a simple format of calling the decode/encode functions.

API and ABI

• This is a breaking change to the module ABI
• This is a breaking change to the module API
• This is a breaking change to the ClientAPI
• This is a breaking change to the SDK API

If the API is breaking, please state below what will break

[kulakowski]

Up to you when to rebase and land this

[kulakowski]

Reorder to alphabetical please.

[kulakowski]

Ditto.

[kim]

I disagree with this. The only reason to move away from the base64 crate seems to be a convenience function, which we could easily define in lib or wherever. I am fairly sure that we would depend on the original base64 crate regardless, even if transitively.

[kulakowski]

I disagree with this. The only reason to move away from the base64 crate seems to be a convenience function, which we could easily define in lib or wherever. I am fairly sure that we would depend on the original base64 crate regardless, even if transitively.

I don't feel strongly. I'll clarify, though, that simple-base64 is a fork of the original base64 and not a wrapper. So there would not be a transitive dependency on it.

[kim]

simple-base64 is a fork of the original base64 and not a wrapper.

Well, that's my point. Because base64 is the obvious choice for the purpose, it is quite likely to be re-introduced either by us or transitively -- which will just make a future audit of our dependency footprint harder.

There are surely reasons to avoid certain crates even if "obvious choice", but then we should ensure that we avoid them entirely (e.g. via cargo deny) and provide ample documentation about what to use instead and why.

I just don't think this is a good reason, because we could solve the perceived nuisance with a wrapper.

[kulakowski]

simple-base64 is a fork of the original base64 and not a wrapper.

Well, that's my point. Because base64 is the obvious choice for the purpose, it is quite likely to be re-introduced either by us or transitively -- which will just make a future audit of our dependency footprint harder.

There are surely reasons to avoid certain crates even if "obvious choice", but then we should ensure that we avoid them entirely (e.g. via cargo deny) and provide ample documentation about what to use instead and why.

I just don't think this is a good reason, because we could solve the perceived nuisance with a wrapper.

Ahh I understand now, I misunderstood and thought you had the specific objection that the new crate itself transitively depended on it.

Yeah. I could see adopting this if other people do, given that? I don't feel as against it as Kim does but certainly see the line of reasoning.

[kulakowski]

@drogus any thoughts about the above discussion?

[kulakowski]

This has been open for a while with unaddressed feedback. I'm going to close it for the sake of making the release process easier (the fewer PRs to scan the easier). Please reopen it if we need to, with the feedback addressed.