GNU bug report logs -
#53400
base64: decode Base64URL
Previous Next
Full log
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Package: coreutils
Currently the base64 util can't parse base64 url safe.
RFC 3548 Base 64 Encoding with URL and Filename Safe Alphabet
https://datatracker.ietf.org/doc/html/rfc3548#page-6
But basically this is the same encoding: just two symbols differ and
no padding. So it's easy and safe just to parse both forms.
The coreutils have a separate command `basenc --base64url` to parse
the b64u but actually there is no any sense to make it as a separate
command.
Having this as a separate command makes it unusable for small Linux
distros like OpenWrt where the device's disk is very small.
Currently **many** shell scripts uses additional transformation like:
```sh
base64_padding()
{
local len=$(( ${#1} % 4 ))
local padded_b64=''
if [ ${len} = 2 ]; then
padded_b64="${1}=="
elif [ ${len} = 3 ]; then
padded_b64="${1}="
else
padded_b64="${1}"
fi
echo -n "$padded_b64"
}
base64url_to_b64()
{
base64_padding "${1}" | tr -- '-_' '+/'
}
```
But this over complicates everything, reduces performance and is error prone.
I created a similar ticked for OpenSSL base64
https://github.com/openssl/openssl/issues/17559
Also as an additional request: can we add the new param `-D` in upper
case which will be an alias to `-d`.
The issue is that on MacOS the small -d was used for debug and they
used the -D in upper case. This creates a lot of problems for scripts
that should work on both Linux and MacOS. So most people use the long
--decode. But many users just don't know about this interop problem
and once I faced a problem when my college gave me a script that
didn't work for me.
This will prevent unexpected compatibility problems.
Regards,
Sergey Ponomarev
This bug report was last modified 3 years and 139 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.