Bug #80870 [Com]: base64_decode: Concatenated base64 blocks are corrupted
| From: | bugs at jth dot net | Date: | Tue, 16 Mar 2021 19:05:30 +0000 |
| Subject: | Bug #80870 [Com]: base64_decode: Concatenated base64 blocks are corrupted | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-232796@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=80870&edit=1
ID: 80870
Comment by: bugs at jth dot net
Reported by: bugs at jth dot net
Summary: base64_decode: Concatenated base64 blocks are
corrupted
Status: Open
Type: Bug
Package: Strings related
Operating System: Linux
PHP Version: 7.4.16
Block user comment: N
Private report: N
New Comment:
> Please, understand, that we are handling emails
> sent to a server from the outside world composed
> by a variety of email clients out of our control
please understand that everybody dealing with email has that issue and solving that properly is far
outside of a naive usage of base64 / string functions
it's far outside of the scope of a programming language
you are wrong here - look how mail-clients linke rouncube written in php deal with emails! again:
you are wrong here, base64_decode alone can't handle emails, period
Previous Comments:
------------------------------------------------------------------------
[2021-03-16 18:59:40] bugs at jth dot net
Please, understand, that we are handling emails sent to a server from the outside world composed by
a variety of email clients out of our control. The emails are handled by a PHP program handling
incoming emails as input to a special service.
Please, relate to the fact that the linux base64 program is handling this case correctly, whereas
base64_decode is corrupting data. There is absolutely no reason for this difference. Correcting it
does not cause any backwards compatibility problems, as I assume nobody is using base64_decode for
generating partly corrupt data.
------------------------------------------------------------------------
[2021-03-16 17:32:18] dgdgeg dot evrgrh at ggg dot ag
your mail client properly deals with mime-mail which is *highly* complex especially when it comes to
nesting
------------------------------------------------------------------------
[2021-03-16 16:48:06] bugs at jth dot net
The case is:
The email program will produce the email body as a valid base64 block and concatenate the selected
signature as a separate valid base64 block. Thus the email body will consist of two valid base64
blocks.
Using the linux base64 program this body is decoded correctly.
As we are using a PHP script to interpret emails from different sources, this base64_decode
behaviour is highly inconvenient and I don't see, why it cannot decode consequtive base64
blocks correctly instead of the current partly corrupted way.
------------------------------------------------------------------------
[2021-03-15 22:20:23] requinix@php.net
= is not valid for Base64 when located in the middle of an input string. As such it will be ignored
(since $strict is not being used) and PHP will attempt to decode
"TGluZSBuciAxIGJjZGVmZwoTGluZSBuciAyIAo=".
The line feed is irrelevant.
What is this "may occur as input from an email"?
------------------------------------------------------------------------
[2021-03-15 20:28:36] bugs at jth dot net
Description:
------------
When decoding a string containing two or more base64 blocks with line feeds in the base64 text the
latter blocks are corrupted.
This may occur as input from an email generated by some mail programs.
Test script:
---------------
$s1 = base64_encode("Line nr 1 bcdefg\n");
$s2 = base64_encode("Line nr 2 \n");
$str = $s1."\n".$s2;
echo $str
echo base64_decode($str);
Expected result:
----------------
TGluZSBuciAxIGJjZGVmZwo=
TGluZSBuciAyIAo=
Line nr 1 bcdefg
Line nr 2
Actual result:
--------------
Result:
TGluZSBuciAxIGJjZGVmZwo=
TGluZSBuciAyIAo=
Line nr 1 bcdefg
(corrupted text)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=80870&edit=1