Obfuscate: Base64URL encoding without pads

Hi everyone.

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."

The method used in obfuscate.go is the variant without padding (RawURLEncoding) base64 package - encoding/base64 - pkg.go.dev).

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.)

Best regards,


Just delete any = off the end of the string to remove the padding.

The padding isn't necessary, strictly speaking, and it makes the strings longer which is why rclone doesn't use it.

Thanks for the message, Nick!

But maybe my points were not clear:

(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.)

Best regards,


Why not use rclone obscure to make the password strings? The actual format of them is an implementation detail and may change in the future.

Hi Nick.

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.

Best regards,

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.