I think padding should be optional (on by default to keep BC)
Of course in user land, simple to write
$enc = trim(base64_encode('foo'), '=');
This proposal allow to simply use
$enc = base64_encode('foo', PHP_BASE64_NO_PADDING);
And also expose it for extension as
PHPAPI extern zend_string *php_base64_encode_ex
(const unsigned char *, size_t, zend_long flags);
Use case: for ARGON2 password hashing
see https://github.com/php/php-src/pull/13635
It may seems ugly to add and remove th padding char
Is a RFC needed for such a minor feature ?
Remi
Link to the PR https://github.com/php/php-src/pull/13698
Hi
Use case: for ARGON2 password hashing
see https://github.com/php/php-src/pull/13635It may seems ugly to add and remove th padding char
Is a RFC needed for such a minor feature ?
Previous related discussion: https://externals.io/message/119243#119243.
My remark about using a cache-timing safe encoder might be relevant for
the argon2 usecase.
Best regards
Tim Düstzerhus
I think padding should be optional (on by default to keep BC)
Of course in user land, simple to write
$enc = trim(base64_encode('foo'), '=');
This proposal allow to simply use
$enc = base64_encode('foo', PHP_BASE64_NO_PADDING);
And also expose it for extension as
PHPAPI extern zend_string *php_base64_encode_ex
(const unsigned char *, size_t, zend_long flags);Use case: for ARGON2 password hashing
see https://github.com/php/php-src/pull/13635It may seems ugly to add and remove th padding char
Is a RFC needed for such a minor feature ?
Remi
Great addition! Only I would strongly prefer a boolean argument over a
flag. Especially now that we have named arguments, adding a bunch of
optional boolean arguments to the signature does not lead to unreadable
code anymore. In fact, I think it yields code that is easier to read.
Regards,
Dik
Le 14/03/2024 à 12:46, Dik Takken a écrit :
Only I would strongly prefer a boolean argument over a flag.
Make sense.
PR updated
I think padding should be optional (on by default to keep BC)
Of course in user land, simple to write
$enc = trim(base64_encode('foo'), '=');
This proposal allow to simply use
$enc = base64_encode('foo', PHP_BASE64_NO_PADDING);
Please add PHP_BASE64_URL flag also.
BASE64 URL encoding (URL safe Base64 encoding) is used everywhere.
i.e. str_replace(['+','/','='], ['-','_',''], base64_encode($str);
https://base64.guru/standards/base64url
Decoding should be extended.
i.e. base64_decode($encoded, PHP_BASE64_URL)
Adding PHP_BASE64_STRICT flag may be reasonable, that requires specific
encoding strictly for decoding.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
And also expose it for extension as
PHPAPI extern zend_string *php_base64_encode_ex
(const unsigned char *, size_t, zend_long flags);Use case: for ARGON2 password hashing
see https://github.com/php/php-src/pull/13635It may seems ugly to add and remove th padding char
Is a RFC needed for such a minor feature ?
Remi
Le 14/03/2024 à 21:31, Yasuo Ohgaki a écrit :
Please add PHP_BASE64_URL flag also.
This is another feature, out of the scope of this PR
Remi
On Fri, Mar 15, 2024 at 9:34 AM Remi Collet Fedora@famillecollet.com
wrote:
Le 14/03/2024 à 21:31, Yasuo Ohgaki a écrit :
Please add PHP_BASE64_URL flag also.
This is another feature, out of the scope of this PR
Remi
Perhaps you should consider it? Base64 "just without" padding isn't really
a standard (that I'm aware of), but url-base64 is and padding is optional.
Simply removing padding (in most real-world cases) isn't enough so this
flag only gets you part of the way there. So, perhaps adding two flags
PHP_BASE64_URL along with this padding flag would be really useful for
those of us having to transform a base64 encoded string to a url-base64.
Robert Landers
Software Engineer
Utrecht NL
Le 13/03/2024 à 17:06, Remi Collet a écrit :
PHPAPI extern zend_string *php_base64_encode_ex
(const unsigned char *, size_t, zend_long flags);
This is done in master
No change in user-land
and no plan from me.
Remi