BASE64_STRICT flag may be reasonable, that requires specific
encoding strictly for decoding.
Regards,
--
Yasuo Ohgaki
yohg...@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);
&
bsolete C module. Do not use)
https://github.com/yohgaki/validate-php-scr (PHP library)
--
Yasuo Ohgaki
yohg...@ohgaki.net
of 134217728 bytes exhausted (tried to
allocate 262144 bytes) in Command line code on line 1
When a fatal error happens, PHP does not allow a stack dump. Very old PHP
allowed users to catch E_ERROR by user error handler, but it is disabled to
prevent users from shooting their own foot.
I supp
2022年9月29日(木) 18:58 Derick Rethans :
> The PHP development team announces the immediate availability of PHP
> 7.4.32.
>
What happened to 7.4.31?
Just curious why it's missing.
--
Yasuo Ohgaki
yohg...@ohgaki.net
2022年9月3日(土) 2:31 Nicolas Grekas :
> Hello everybody, hi Mate
>
> I played with readonly classes recently, to add support for them to
> lazy-loading proxy generation and I struggled upon what I see as serious
> issues.
>
> As noted in the RFC, and because the readonly flag must be set on child
>
in your webserver.
>
For example, password hash DoS attack was made possible because PHP allows
8MB post data.
https://www.acunetix.com/vulnerabilities/web/long-password-denial-of-service/
IIRC, Drupal has a security release for this.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
, PHP script that handles large POST data should increase these
settings.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi,
The name "is_trusted" is misleading.
Literal is nothing but literal.
Literals cannot always be trusted.
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Tue, Jun 22, 2021 at 5:25 AM Craig Francis
wrote:
> On Sat, 12 Jun 2021 at 18:00, Craig Francis
> wrote:
>
&g
https://museum.php.net/
This one is invalid also.
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Mon, Jun 3, 2019 at 9:26 PM Sascha Schumann <
sascha.schum...@myrasecurity.com> wrote:
> Will be fixed in a few minutes. Thanks for the report.
>
> Sascha
y for hex/octal/bit.
Hex may be grouped by 2,4,8,16,32 and so on. Bit fields may be grouped by
any length.
Regards,
P.S. Even if it's easier for us, we don't use 1, normally at least
today.
--
Yasuo Ohgaki
yohg...@ohgaki.net
nder how many container setups relay on open_basedir as
additional security.
Regards,
P.S. Anyone shouldn't rely on stack smashing attack protection, yet
it's still there for sail safe purpose. open_basedir is fail safe feature.
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Fri, Apr 12, 2019 at 5:32 AM Michael Morris wrote:
> Submitted to the floor is a Wired article from 2 days ago I came across
>
>
> https://www.wired.com/story/coding-is-for-everyoneas-long-as-you-speak-english/
>
> The manual of PHP is translated into multiple languages - but what are the
>
On Tue, Apr 16, 2019 at 10:55 PM Bishop Bettini wrote:
> On Tue, Apr 16, 2019 at 6:38 AM Yasuo Ohgaki wrote:
>
>> On Mon, Apr 15, 2019 at 3:28 PM Stanislav Malyshev
>> wrote:
>>
>> > Hi!
>> >
>> > > Thanks for responding to this iss
.
https://github.com/php/php-src/blob/master/ext/phar/phar.c#L607
I'm not sure if Phar metadata requires object or not.
If not, Phar may use JSON. Or we may add safer unserialize that ignores
object
and reference for maximum compatibility.
Something has to be done, since we wouldn't fix memory iss
George Peter Banyard
>
> [1] https://secure.php.net/manual/en/function.fopen.php
If a developer decides to write sloppy code, then @ may be acceptable.
I wouldn't use @, though.
IMO, there should be INI switch that kills @ operator.
There is extension module for this purpose, but PHP itself should have it.
@ operator is convenient, but @ is evil and make debugging a lot harder.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
opers dislike inconsistent names, prefer
to enter extra few chars.
Consistent name isn't big deal, but keeping inconsistent names for good
doesn't sound nice.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Wed, Jan 23, 2019 at 7:08 AM Girgias wrote:
> On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki wrote:
>
>> Hi Girgias
>>
>> It seems good list in general.
>> There would not be issues marking them as deprecated.
>> "Deprecation" means "Soft depre
> either.
>
Candidates are these
https://wiki.php.net/rfc/consistent_function_names
>From previous discussion, I think it would be better to keep both PHP and
POSIX names.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
pg_loopen()/etc were there until nobody cares about these
aliases.
New names, pg_lo_open()/etc, were given in PHP4.x. These changes were
documented since PHP 4.x.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
https://wiki.php.net/rfc/source_files_without_opening_tag
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
various way to embed session ID in page / request,
finding actual state by user script is not a simple task. i.e. Just checking
session ID cookie is not good enough by session module spec. Session ID
can be stored in URL path, query, POST parameter and cookie.
Any comments?
--
Yasuo Ohgaki
yohg
On Mon, Aug 6, 2018 at 5:53 PM Yasuo Ohgaki wrote:
>
>
> On Mon, Jul 30, 2018 at 6:51 PM Andrey Andreev wrote:
>
>> On Mon, Jul 30, 2018 at 5:46 AM, Yasuo Ohgaki wrote:
>> > On Sun, Jul 29, 2018 at 9:27 PM Andrey Andreev
>> wrote:
>> >>
>>
On Mon, Jul 30, 2018 at 6:51 PM Andrey Andreev wrote:
> On Mon, Jul 30, 2018 at 5:46 AM, Yasuo Ohgaki wrote:
> > On Sun, Jul 29, 2018 at 9:27 PM Andrey Andreev wrote:
> >>
> >> Hi,
> >>
> >> On Sun, Jul 29, 2018 at 7:22 AM, Yasuo Ohgak
On Sun, Jul 29, 2018 at 9:27 PM Andrey Andreev wrote:
> Hi,
>
> On Sun, Jul 29, 2018 at 7:22 AM, Yasuo Ohgaki wrote:
> >
> > One thing regarding implementation.
> > Since the internet RFC has only 2 values for "samesite", the parameter
> can
> > be
session_oo. c or like and define OO APIs in it. It requires a new RFC for
this.
One thing regarding implementation.
Since the internet RFC has only 2 values for "samesite", the parameter can
be
bool rather than string so that users can avoid "broken security by a typo".
If "samesite" has more than 2 values, the INI handler can be changed so
that it can
handle both bool and string parameters.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
to count number of all illegal chars in the db before
converting
data. "illegal_chars" is handy for this.
Old data may be added to converted data by using base64 if it's necessary.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
downgrade
Invalid UTF-8 data stored in bug db can result in broken pages.
How about convert invalid data into URL encoded data or something else?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
y *ignore* typehints and work like they are not
> there.
>
What you need is DbC.
It's more flexible and complete. It satisfies all of your needs and more.
An issue is that DbC is not static code analysis tool friendly.
https://wiki.php.net/rfc/introduce_design_by_contract
https://wiki.php
y can
if (array_key_last($array) === NULL) { // Or if (!count($array)) {
die("hey, no value defined");
}
$var = array_value_last($array);
This usage would be rare and use of ($array[array_key_last($array)] ??
null) for null coalesce is pain.
It lacks API consistency as well.
Therefore, I voted "yes" for both.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
their
own foot. There are features like "friend", e.g. $GLOBALS
I understand concerns, however simpler/cleaner production classes without
test only methods and having detailed tests is worth to have.
I would like to vote to "yes".
However, RFC does not have benchmark result. Do you have some results?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
mpatibility between current "continue" and "break",
how about provide a tool replace "continue" to "break" where it is
applicable.
(Raise error for invalid "continue" usage also. This would be a bug most
likely.)
Then there wouldn't be compatibility issue anymore.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sat, Jun 30, 2018 at 11:42 AM, Tim Starling
wrote:
> On 30/06/18 11:44, Yasuo Ohgaki wrote:
> > readline has license issue. I miss it but I wouldn't object for removing
> it.
> > Let's use libedit for CLI by default and always.
> > Issue may be who is going to do this.
;
>
> Actually, readline support in "php -a" is part of the extension. The
> extension hooks the SAPI module. See PHP_MINIT_FUNCTION(cli_readline)
> in readline_cli.c.
>
> Readline is the only extension in your list that I would be sad about
> losing. I use it every day
and so on. (I once moved that functionality from SAPI/cli to
> ext/readline to satisfy distributors who didn't want to statically link
> readline for license and related reasons)
>
> johannes
CLI without readline isn't good.
--with-libedit is there to replace readline lib.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
re consequence of "readline" removal.
With CLI, "php -a" and "history" works without readline?
Does it work as dynamically loaded module?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
ng "type hint" a "true type hint" is useful with DbC as well as static
analysis tools.
Perhaps,
declare(strict_types=-1); // -1 indicates assert() type check. i.e. asset
is disabled, no type checks.
How it should behave with object would be debatable.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
change, there are ways to write code
that work in any PHP versions.
session_name('new_name') can be called while session is inactive in this
case. i.e. session_commit(); session_name('new_name'); session_start();
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
uch better validation than simple type checks.
function f($username) {
assert(is_string($username) && preg_match('\\A[a-z]\\z', $username);
}
--
Yasuo Ohgaki
yohg...@ohgaki.net
ntp, etc.
However changing output by default as follows is enough for it.
+
uniqid() is one of the most abused function in PHP.
I don't have strong opinion against uniqid() deprecation, though.
Regards,
--
Yasuo Ohgaki
this.
Btw, you can use the validator for a single value validation as well. It
also able to
disable Exception so that one can use it for "Business Logic Validations"
as well.
https://github.com/yohgaki/validate-php-scr/tree/master/src/examples
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
ntal requirement for programs to work correctly.
Fundamental requirement: Programs can only work correctly with valid inputs.
There are countless reason why one should validate ALL inputs other than
this.
Almost nobody does this now, even if it is "fundamental" requirement.
How you would solve this?
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Mon, Sep 4, 2017 at 3:33 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi all,
>
> I spent a little time for a new input validation module. It's not totally
> new module, but is based on Filter module's validation filter improvement
> RFC in many ways. [1]
>
> As al
are better to implement it in the session module. IMO.
Current OWASP session management cheat sheet
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_Expiration
defines idle/absolute/renewal timeouts. PHP cannot handle any of them
properly.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
the 1st tional parameter at
least, or
better, it should be a required parameter.
I might be +1 depending on the behavior, but -1 as long as their attitude
is acceptable.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
)
>
Consistent function names at the same time, perhaps?
https://wiki.php.net/rfc/consistent_function_names
--
Yasuo Ohgaki
yohg...@ohgaki.net
/master/ext/standard/array.c#L2459
Since it checks valid flags, we wouldn't have compatibility for current
versions unless
released versions code is modified for it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Fri, Sep 15, 2017 at 6:06 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> On Wed, Sep 13, 2017 at 3:24 PM, Joe Watkins <pthre...@pthreads.org>
> wrote:
>
>> This proposal was rejected.
>>
>> 6 months has not passed since it was rejected.
>>
you have great responsibility as RM for ridiculous hash_hkdf() API.
Current hash_hkdf() API is perfectly makes sense for you. I understand it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Tue, Sep 12, 2017 at 1:04 PM, Stephen Reay <php-li...@koalephant.com>
wrote:
>
> On 12 Sep 2017, at 04:07, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
> Stephen,
>
> On Tue, Sep 12, 2017 at 12:22 AM, Stephen Reay <php-li...@koalephant.com>
> wrote:
>
&g
Session security and input data security discussion have similar pattern.
I insists based on standards and/or guidelines, others just ignore
standards/guidelines/security because they don't use/are not familiar with
them.
If it is simply a matter of preference, it would be acceptable. However,
in case o
Hi,
On Tue, Sep 12, 2017 at 6:54 AM, li...@rhsoft.net <li...@rhsoft.net> wrote:
>
>
> Am 11.09.2017 um 23:39 schrieb Yasuo Ohgaki:
>
>> On Tue, Sep 12, 2017 at 6:35 AM, li...@rhsoft.net but you still fail
>> to explain why in the world you don#t try to
>
Hi,
On Tue, Sep 12, 2017 at 6:39 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi,
>
> On Tue, Sep 12, 2017 at 6:35 AM, li...@rhsoft.net <li...@rhsoft.net>
> wrote:
>
>>
>> Am 11.09.2017 um 23:07 schrieb Yasuo Ohgaki
>>
>>>
Hi,
On Tue, Sep 12, 2017 at 6:35 AM, li...@rhsoft.net <li...@rhsoft.net> wrote:
>
> Am 11.09.2017 um 23:07 schrieb Yasuo Ohgaki
>
>> On Tue, Sep 12, 2017 at 12:22 AM, Stephen Reay <php-li...@koalephant.com>
>>
>>> So, you still didn’t actually provid
Hi Stephen,
On Tue, Sep 12, 2017 at 6:07 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Would you like me to propose previous RFC again?
> and implement "ture validation" with filter?
> I don't mind implementing it if you would like to update the RFC and it
> passe
Stephen,
On Tue, Sep 12, 2017 at 12:22 AM, Stephen Reay <php-li...@koalephant.com>
wrote:
>
> On 11 Sep 2017, at 17:41, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
> Hi Stephen,
>
> On Mon, Sep 11, 2017 at 6:37 PM, Stephen Reay <php-li...@koalephant.com>
&
Hi Stephen,
On Mon, Sep 11, 2017 at 6:37 PM, Stephen Reay <php-li...@koalephant.com>
wrote:
> On 11 Sep 2017, at 15:42, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
> It seems you haven't try to use filter module seriously.
> It simply does not have enough feature for input
Hi Tony,
On Sat, Sep 9, 2017 at 6:26 PM, Tony Marston <tonymars...@hotmail.com>
wrote:
> "Yasuo Ohgaki" wrote in message news:CAGa2bXa4UvkL-ZsLAB2bF05L
> 4q_oduixszvvyzu9nddksvt...@mail.gmail.com...
>
>>
>> Hi Tony,
>>
>>
>
>>
>
Hi Niklas,
On Fri, Sep 8, 2017 at 7:27 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi Niklas,
>
> On Fri, Sep 8, 2017 at 6:38 PM, Niklas Keller <m...@kelunik.com> wrote:
>
>> I finally find out what's wrong.
>>>
>>
>> No, you didn't. Y
r reading material: https://eprint.iacr.org/2010/264.pdf
>
Thank you nice reading. I've read briefly.
It sounded like SHA-2 and SHA-3 difference that could be ignored in
practice now.
Now issue is whether we'll fix the improper and inconsistent API or not.
Thank you Niklas,
--
Yasuo Ohgaki
yohg...@ohgaki.net
eter is the evidence.
No wonder why you couldn't present reasonable example codes w/o salt.
Salt should/must be used for both strong and weak keys for better and
mandatory security.
Regards,
P.S. Thank you Niklas! Now we will have conclusion.
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Fri, Se
ot;.
Obviously, the RFC is prepared for weak keys and it is perfectly OK to
use weak keys unlike Andrey statement.
If IKM should be strong always, HKDF would NOT have salt at all.
However, HKDF has salt.
Weak IKM is explicitly allowed by HKDF definition.
Andrey, sorry for my confusion, but your claim is wrong by HKDF
(HMAC) definition still.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Andrey,
On Fri, Sep 8, 2017 at 8:14 AM, Andrey Andreev <n...@devilix.net> wrote:
> Hi,
>
> On Fri, Sep 8, 2017 at 12:32 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> >
> > The reason why latter is a lot more secure is related to Andrey's
> >
ameter.".
However, do we really keep this mess forever? for a new function?
(BTW, Nikita, are you going to take your statement back or not. It's too
impolite)
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Wed, Sep 6, 2017 at 10:15 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi all,
>
nt validations can cooperate if it is
possible.
I'm very interested in PDO level validation because SQLite3 could be very
dangerous.
(i.e. Type affinity allows store strings in int/float/date/etc) It may be
useful if PDO
can simply use "validate" module's rule or API.
BTW, Input validation should only validate format(used char, length, range,
encoding)
if we follow single responsibility principle. Logical correctness is upto
logic. i.e. Model in
MVC.
Anyway, goal is providing usable basic validator for core features and
security.
Required trade offs may be allowed.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Dan,
Sorry for keep posting broken English.
I shouldn't difficult.
>
It shouldn't be difficult.
Looking forward more than handful, useful and common hash_hkdf()
application
examples for PHP that justify the API. If you would not like to spend time
for working
code, just ideas are OK also.
Hi Dan,
I appreciate your feedback, regardless of your opinion towards this issue.
On Wed, Sep 6, 2017 at 8:04 PM, Dan Ackroyd <dan...@basereality.com> wrote:
> On 6 September 2017 at 02:15, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> > What should we do for this?
&
ite code - see below.
>
> > Which is why Yasuo and I have both suggested we work together
>
> If you're going to work together and continue the conversation, please
> can you move this conversation elsewhere?
>
> It doesn't appear to be actually anything to do with PHP intern
o take it back. I respect your contributions much,
but
the last one you've said is out of tolerance.
--
Yasuo Ohgaki
yohg...@ohgaki.net
code is mess)
Since the last attempt was failed, new module would be the next reasonable
attempt.
On Wed, Sep 6, 2017 at 4:39 AM, Lester Caine <les...@lsces.co.uk> wrote:
> On 05/09/17 20:05, Yasuo Ohgaki wrote:
> > There is one principle that developers is better to fo
. We may cooperate so that there aren't unnecessary validaiton
rule incompatibilities.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Lester,
On Tue, Sep 5, 2017 at 8:36 PM, Lester Caine <les...@lsces.co.uk> wrote:
> On 05/09/17 12:18, Yasuo Ohgaki wrote:
> > I cannot guess people's thought. I appreciated feedback!
>
> With a decent database layer a lot of the validation you are proposing
> is alre
alidator();
$violations = $validator->validate('Bernhard', array(
new Length(array('min' => 10)),
new NotBlank(),
));
However, this particular validation class seems it could be good one that
wraps
validate module for nicer OO API and faster execution.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
+Practices
[3]
https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide
--
Yasuo Ohgaki
yohg...@ohgaki.net
,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Fri, May 12, 2017 at 8:37 PM, Dan Ackroyd <dan...@basereality.com> wrote:
> This conversation appears to have reached an end.
>
Indeed.
No example usage that justifies current signature.
It proves what was wrong. I'll post final doc patch in new thread.
Regards,
--
Yasuo
u cannot think of any, you should admit your misunderstanding,
shouldn't you?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Wed, May 10, 2017 at 7:21 AM, li...@rhsoft.net <li...@rhsoft.net> wrote:
> Am 09.05.2017 um 23:36 schrieb Yasuo Ohgaki:
>
>> Hi,
>>
>> On Sun, Apr 30, 2017 at 3:55 PM, li...@rhsoft.net > li...@rhsoft.net> <li...@rhsoft.net <mailto:li...@rhsoft.net&g
Hi Andrey,
On Sun, Apr 30, 2017 at 8:26 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> On Sun, Apr 30, 2017 at 8:14 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
>> I don't need your view of HKDF RFC or usage, but I do need good practical
>> examples that just
rently not.
You obviously do not understand what is the issue.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sun, Apr 30, 2017 at 8:14 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> I don't need your view of HKDF RFC or usage, but I do need good practical
> examples that justify your point of view. Please don't waste of your/my
> time,
> just give some good examples in next rep
Hi Andrey,
On Tue, Apr 25, 2017 at 7:17 PM, Andrey Andreev <n...@devilix.net> wrote:
> Hi,
>
> On Tue, Apr 25, 2017 at 3:28 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> >>
> >> If you want examples, search GitHub for PHP code utilizing HKDF - you
> >
On Tue, Apr 25, 2017 at 9:28 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> I don't think the author wouldn't make such mistake, so I checked.
>
Oops. Double denial.
I thought the author wouldn't make such mistake, so I checked.
--
Yasuo Ohgaki
yohg...@ohgaki.net
hat everybody is wrong
> and you alone are right? Give it up already.
Prove my idea in the manual (or my RFC) is wrong by logic, rather than FUD.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
nd your idea.
Most of the changes are based on what is _written_ in the RFC 5869
I'm a bit tired with arguments without valid logic.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Sat, Apr 15, 2017 at 9:17 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> My opinions are either based on concrete logic or
> recommendations based reliable sources.
>
> I improved hash_hkdf() manual farther more based on RFC 5869 descriptions.
> https://gist
es.
I improved hash_hkdf() manual farther more based on RFC 5869 descriptions.
https://gist.github.com/anonymous/ace4fa267f20041676f265fe58c3f1ea
Please verify it again.
Regards,
P.S. I'm a human, so I make mistakes. I appreciate if one could
point out when my logic is wrong.
--
Ya
"Key that validates the _authentic_ request".
It is obvious that expiration enabled URI specific CSRF token is
a lot secure than common static CSRF tokens that are valid for all requests.
How this could be bad example?
128 bit entropy key for AES 256 is simply bad practice like
$aes256key = hash('sha256', 'mypassword', true);
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Fri, Apr 14, 2017 at 6:22 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
> On Thu, Apr 13, 2017 at 5:11 PM, Pieter Hordijk <i...@pieterhordijk.com>
> wrote:
>
>> Is this really something we need in our official docs instead of for
>> example
>>
hkdf example
+
+
+
@@ -130,6 +286,7 @@
+hash_hmac
hash_pbkdf2
RFC 5869
userland
implementation
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Pieter,
On Thu, Apr 13, 2017 at 5:38 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
> On Thu, Apr 13, 2017 at 5:11 PM, Pieter Hordijk <i...@pieterhordijk.com>
> wrote:
>
>> To be honest I am afraid of ending up with something like the current
>> state
>&
.
See the difference hash_hmac() and hash_pbkdf2(). hash_pbkdf2() is older
KDF function. I should have mention in the RFC :(
--
Yasuo Ohgaki
yohg...@ohgaki.net
nced CSRF token.
Andrey,
Could you give us some length only and length/info only example
that could be useful for most PHP users.
It should be safe and recommended usage.
I suppose you should have some good examples.
Thank you.
--
Yasuo Ohgaki
yohg...@ohgaki.net
thods.
invariant check
is even more difficult.
The most important DbC merit is "Ensured program correctness", then
security.
Performance would be the least important for PHP as you mentioned.
P.S. DbC is not a Unit Test replacement. Unless there is Unit Test,
pre/post/invariant
conditions c
ns/methods at
development time.
e.g.
function save_age($user_age)
require (is_int($user_age))
require ($user_age >= 0)
require ($user_age < 150)
{
save_to_somewehre($user_age);
}
//Note: All input parameters must be validated to be correct value for the
app. e.g. use filter_validate()/etc
What you really need might be DbC.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
o only superficially scanned
> https://github.com/gvanas/KeccakCodePackage#under-which-
> license-is-the-kcp-distributed
> but it looked like it should be ok. Not an expert on this though ;-)
>
It's fine for me.
I'll wait few weeks for more comments.
If not, I'll merge your PR to master.
I don't think we really need to merge it to released version.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
two functions.
>
Nice finding.
https://github.com/phusion/digest-sha3-ruby
seems a little old. It may not implement final version.
Whichever is wrong, we may be better look into this.
Anyway, it seems someone is better to try to improve SHA3 performance.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Sara,
On Sat, Apr 1, 2017 at 12:24 PM, Sara Golemon <poll...@php.net> wrote:
> On Fri, Mar 31, 2017 at 10:12 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> > I noticed that our SHA-3 is inefficient.
> >
> Entirely possible. Feel free to improve it. :D
I
sys 0m0.005s
As you can see, PHP's SHA3 is about 6 times slower.
According to DJB's benchmark, it seems SHA-3 could be as fast as SHA-2.
https://bench.cr.yp.to/results-sha3.html
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
- insecure signature (it ignores strong RFC 5689 recommendation)
s/RFC 5689/RFC 5869/
On Sat, Apr 1, 2017 at 11:27 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
> Given that the function is live in the wild, massively changing the order
>> of things and defaults
for new function.
Yes, if there are more secure defaults that would be nice, but that ship
> has sailed, and the function was on it.
Thank you for your comment.
I would like to try to fix it at least.
To avoid this kind of confusions, we are better to have RFC if there is
strong objection.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
1 - 100 of 1719 matches
Mail list logo
