I am now using rclone in a couple of projects. Thanks to the community for all the work!
Recently, while embedding it in setups for confidential computing. I went to use the crypt backend with a tool for creating and managing password (so that no human would ever see the crypt passwords and I could revoke their access without reencrypting things). I used Scone (https://sconedocs.github.io/) but ran into a problem with the base64 encodings.
According to section 3.2 of RFC4648: "Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise."
So, my question is: Is there a reason for not using padding there? My understanding was that without compelling reasons for not using, we should use. (I did a patch that replaced the current no-pad variant with the pad variant and it worked.)
(1) (Manually) Fixing the padding is trivial, but my point is that there is no manual intervention. I create a template pointing where a "base64" password should be inserted. And no other application or human will ever see the password. I put only a placeholder.
(2) If the RFC states that padding should be there and both cases are trivial, isn't it better to just have it? (Or maybe there was a more complex reason that I did not catch.)
Thanks for the suggestion. Using rclone obscure is an alternative. I will think about the tradeoffs between (1) having a "sed" to replace RawURLEncoding with URLEncoding in my Dockerfile when compiling a confidential rclone (which is what I do today) and (2) adding an extra pipeline stage that generates a password with rclone-obscure and submits it to the key vault.