Hi Christoph,
Yes, https://github.com/php/php-src/pull/3311 is the correct merge request.
---
Charles R. Portwood II
On Jun 19, 2018, 10:28 AM -0500, Christoph M. Becker , wrote:
> On 19.06.2018 at 17:12, Charles Portwood wrote:
>
> > The RFC has been accepted 17-0 in favor of ad
Hello Internals,
The RFC has been accepted 17-0 in favor of adding this to PHP 7.3. A merge
request with the implementation is available at
https://github.com/php/php-src/pull/1997 for review and merging into 7.3 when
ready.
Thanks,
---
Charles R. Portwood II
On Jun 6, 2018, 5:54 PM -0500
Hello Internals,
The RFC for including Argon2id in password_* functions is now open for a
vote. The RFC is available at
https://wiki.php.net/rfc/argon2_password_hash_enhancements.
Voting will be open until June 18th, 2018.
Thank you.
---
Charles R. Portwood II
On Feb 5, 2018, 9:43 AM -0600, Charles R. Portwood II
, wrote:
> Hello Internals,
>
> I would like to propose adding Argon2id to the password_* functions in PHP
> 7.3.
>
> An RFC[1] has been prepared which covers implementation details, and some
> common questions &
ttps://wiki.php.net/rfc/argon2_password_hash_enhancements
[2]: https://github.com/php/php-src/compare/master...
charlesportwoodii:argon2_password_hash_enhancements?expand=1
---
Charles R. Portwood II
On Thu, Sep 8, 2016 at 10:09 AM, Christoph M. Becker
wrote:
> On 08.09.2016 at 16:26, Charles R. Portwood II wrote:
>
> > On Wed, Aug 24, 2016 at 10:49 AM, Charles R. Portwood II wrote:
> >
> >> The RFC for introducing Argon2 as an alternative hashing algorit
On Wed, Aug 24, 2016 at 10:49 AM, Charles R. Portwood II wrote:
> Hello,
>
> The RFC for introducing Argon2 as an alternative hashing algorithm for the
> password_* functions is now re-open. The RFC is available at
> https://wiki.php.net/rfc/argon2_password_hash
>
>
>
>
On Wed, Aug 24, 2016 at 10:49 AM, Charles R. Portwood II wrote:
> Hello,
>
> The RFC for introducing Argon2 as an alternative hashing algorithm for the
> password_* functions is now re-open. The RFC is available at
> https://wiki.php.net/rfc/argon2_password_hash
> .
>
> V
previously voted you will need to vote
again, as the original vote was closed shortly after opening due to an
issue with the original RFC language.
Thanks!
*Charles R. Portwood II*
On Sat, Aug 6, 2016 at 12:55 PM, Charles R. Portwood II <
charlesportwoo...@erianna.com> wrote:
>
>
> I think there's a bunch of ways we can tweak this. As there's no "bad"
> values for any of these cost factors per the spec, it may just be easy to
> se
o
verify Argon2 hashes created with a hash key and associated data without
changing the PHP API for that function.
*Charles R. Portwood II*
On Sat, Aug 6, 2016 at 11:37 AM, Lauri Kenttä
wrote:
> On 2016-08-06 17:47, Charles R. Portwood II wrote:
>
>> Absolutely. What are your thoughts on the following cost factors?
>>
>> time_cost = 3
>> memory_cost = 12
>> threads = 1
>>
>> The refe
On Sat, Aug 6, 2016 at 6:09 AM, Niklas Keller wrote:
> 2016-08-05 22:51 GMT+02:00 Lauri Kenttä :
>
>> On 2016-08-05 21:20, Charles R. Portwood II wrote:
>>
>>> On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster wrote:
>>>
>>>>
>>>> I can u
On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster wrote:
>
> I can understand an argument that it's too much to expect a user to
> provide an options array when using Argon2. But I don't understand how my
> suggestion breaks BC. In my idea, a future RFC would propose default cost
> constants. Changing
hind not providing
defaults.
A separate RFC would be needed for 7.4 to make PASSWORD_ARGON2I =
PASSWORD_DEFAULT). If the supplied constants need to be changed for that, I
think that would be the time to do so. I think for now something needs to
be provided to ensure the password_hash API doesn'
On Fri, Aug 5, 2016 at 9:49 AM, Charles R. Portwood II <
charlesportwoo...@erianna.com> wrote:
> On Fri, Aug 5, 2016 at 9:19 AM, Tom Worster wrote:
>
>> On 8/5/16 8:47 AM, Charles R. Portwood II wrote:
>>
>> The RFC is available at: https://wiki.ph
On Fri, Aug 5, 2016 at 9:19 AM, Tom Worster wrote:
> On 8/5/16 8:47 AM, Charles R. Portwood II wrote:
>
> The RFC is available at: https://wiki.php.net/rfc/argon2_password_hash
>>
>> .
>>
>
> Hi Charles,
>
> Thanks for doing this. I'm glad Argon2
ly to discuss the matter on Monday,
and for your feedback on these changes.
*Charles R. Portwood II*
On Mon, Aug 1, 2016 at 3:27 PM, Charles R. Portwood II <
charlesportwoo...@erianna.com> wrote:
> On Mon, Aug 1, 2016 at 3:16 PM, Davey Shafik wrote:
>
>> On Mon, Aug 1, 2016 at 1:13 PM, Charles R. Portwood II <
>> charlesportwoo...@erianna.com> wrote:
>>
&g
On Mon, Aug 1, 2016 at 2:41 PM, Davey Shafik wrote:
> On Mon, Aug 1, 2016 at 12:35 PM, Davey Shafik wrote:
>
>> On Mon, Aug 1, 2016 at 10:46 AM, Charles R. Portwood II <
>> charlesportwoo...@erianna.com> wrote:
>>
>>> Hello,
>>>>
>>>&g
those need to be adjusted please
let me know.
Thanks!
*Charles R. Portwood II*
Hello Internals,
I'd like to propose the implementation of the Argon2 hashing library into
the password_* functions, and would like to open this RFC to further
discussion.
RFC: https://wiki.php.net/rfc/argon2_password_hash
Thank you,
*Charles R. Portwood II*
;
> On Sun, Jul 10, 2016 at 1:24 AM, Pierre Joye wrote:
>
>>
>> On Jul 10, 2016 2:38 AM, "Charles R. Portwood II" <
>> charlesportwoo...@erianna.com> wrote:
>> >
>> > Hello Internals,
>> >
>> > I'd like to improve th
password_*
functions. I would handle implementation of this enhancement, and would
like to gather your feedback before formally proposing an RFC.
My wiki username is: charlesportwoodii
Thank you!
*Charles R. Portwood II*
[1] <https://github.com/P-H-C/phc-winner-argon2>
[2] <https://passwo
There was a previous discussion on the return value of
SplFileObject::__toString being
an alias to SplFileObject::current() but that was about the design decision
why and not
really suggesting any kind of change or a technical error. In the
discussion it was
established that:
(1) Changing this wou
This feels like a bug to me. Why would SplFileObject::__toString return the
current line while SplFileInfo::__toString returns file path?
On Tue, Jan 29, 2013 at 5:51 PM, Ferenc Kovacs wrote:
> On Tue, Jan 29, 2013 at 11:29 PM, hakre wrote:
>
> > Can somebody shed some light why:
> >
> >
This patch has been awaiting review for over a month. Is there anything
I can do to help hurry things along?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
imap_fetch_overview() presently does not include any information on when
the remote store has last been updated. Not having this information can
force IMAP clients to make more requests than should strictly be
necessary, and a ticket requesting it has been open since 2006. (As an
aside -- my em
();
usage:
$db=pg_connect(...);
$db_socket = pg_get_socket($db);
pg_send_query("select 1,pg_sleep(3)");
stream_select($db_socket, ...);
pg_get_result($db);
feature was requested Jan 2005 on
the pg_get_result page of the main English manual.
-Charles
diff -c pgsql_old/php_pgsql.h pgsql/p
submit and maintain packages on PEAR
(I have HTML_Entities finished, and File_Sitemap proposed)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
VOur team of Sci my enti xze sts spent years developing a pr wv od vfw uct that
will safely
and effe wkg ctiv fp ely add le odn ng dx th, wi ty dt pzr h, and st umo ren nu
gth to any man's p bof en gfo is.
The work has created a pr mz od mw uct that has been shown to sig st nifi av
can ev tly in
Contributing to PEAR package 'Date'
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ron Korving wrote:
>The last item in the array is replaced, not by the first one of the second
>foreach, but by the item before the last item. That just doesn't make sense
>at all.
>
>
This is where you're going wrong (and where I was going wrong in
thinking about this before Antony's message).
Enjoy your presumptions, I'm sure they're great fun at parties.
Robert Cummings wrote:
> Also,
>quite probably unlike you, many of us programmer try to make our code
>perfectly clean from notices and warnings
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
Either way, I really don't think it's worth any fuss. It's just a
notice, and whether it is there or not shouldn't really matter that
much. This doesn't deserve all the attention it's been getting on this list.
Robert Cummings wrote:
>My soul didn't curdle and fall out of my ears before the notic
It's a notice. Your soul won't curdle and fall out of your ears just
because your code produces a notice which you can easily prevent from
being output.
Robert Cummings wrote:
>I think the reference notice stuff is a bit ridiculous. I mean I can
>understand the concern behind:
>
>function &fo
I can't say I'm quite sure why anyone is continuing to argue against
something that's already been denied, especially in a thread about
ending the argument.
David Zülke wrote:
Fookin' Jaysus man.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
Jacques Marneweck wrote:
I think the mailling lists strip attachments?
Attaching a file to this message to test the theory.
For the list of people who've put work into PHP, please see
http://www.php.net/credits.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
Yermo Lamers wrote:
I've not had alot of luck with reporting bugs through the bug tracker;
For instance see
http://bugs.php.net/31508
where the guy claims PHP can't do recursion without crashing ... Ummm?
To be fair, he is correct in what he says; PHP cannot do recursion
beyond a certain level,
Christian Schneider wrote:
Matthew Charles Kavanagh wrote:
Perhaps you're not seeing my point, or perhaps you don't care about
users? I speak as a developer, not as some guy with a crap webhost, and
So according to you every single extension should be put bundled and
installed by d
Derick Rethans wrote:
On Fri, 4 Mar 2005, Matthew Charles Kavanagh wrote:
The issue in my mind is one of portability. It would be nice, as a
developer working in PHP, to be able to rely on functionality like
encryption (and other unrelated goodies) being available on Joe User's
$5/month we
(earlier message, sending to list)
Derick Rethans wrote:
This is definitely not planned - we rather not bundle any library, and
definitely not an LGPL library.
Reinventing the wheel by providing encryption routines in PHP does not
make sense really. PHP is meant to be a glue to provide access to
li
David Zülke wrote:
Guys, I'm sure I'll annoy the heck out of some on this list, but there's
still the question whether PHP should prevent any case of dumbness on the
developer side. Whatever we do, some developers out there will be way more
idiotic than we can ever imagine. And if any company chose
43 matches
Mail list logo
