[prev in list] [next in list] [prev in thread] [next in thread] 

List:       coreutils-bug
Subject:    bug#66265: Make padding optional with base64
From:       Pádraig Brady <P () draigBrady ! com>
Date:       2023-09-29 14:11:55
Message-ID: 4a14b177-0a55-87a7-157a-8a4b7ed37e4d () draigBrady ! com
[Download RAW message or body]

On 29/09/2023 10:46, Paul Millar wrote:
> Hi,
> 
> RFC 4648 says[1]:
>   >   In some circumstances, the use of padding ("=") in base-encoded data
>   >   is not required or used.
> 
> Currently, the 'base64' application always includes the padding when
> encoding, and prints an warning/error message (on stderr) if padding is
> omitted when decoding.  Decoding is nonetheless successful (the correct
> data is emitted on stdout) if the base64-encoded data omits the padding.
> 
> I think the base64 application should be updated to support
> base64-encoded data without padding.
> 
> My suggestion would be to add an option to base64 to control whether
> padding is added when encoding.  For decoding, it might make sense to
> add an option to control whether padding is expected.
> 
> (although, other approaches might be possible)
> 
> Cheers,
> Paul.
> 
> [1] https://datatracker.ietf.org/doc/html/rfc4648#section-3.2

I agree with this actually.

The main advantage of padding as I see it is when concatenating encoded data.
I.e. that's the only use case where there could be ambiguity in the received
encoded data, as otherwise one can auto assume appropriate padding based on
the input length. I can't see `base64` or `basenc --base64` being used in a
problematic streaming context like that. If the utils themselves read from
a stream in a _single invocation_ they'll deal with partial blocks appropriately.
Looking at it another way, I don't see how base64 data over _separate invocations_
of these utils could be handled now, as they just give errors in this case anyway.
Now there would be a slight loss in error detection as truncated data would
not be noticed, however that is the case for a third of truncated sizes already.

So on input I'm inclined to auto pad.

On output one can trivially remove padding with `tr -d =`,
so I'm inclined to leave that as is.

I.e. we shouldn't need a new option for any of this.

cheers,
Pádraig



[prev in list] [next in list] [prev in thread] [next in thread]