Also, be aware that BCrypt only uses the first 72 characters of the
password field. So if you use a hex encoded sha512 output, a good deal
of entropy would be lost (almost half of it)...
Good to know, do most hash algorithms have limitations on the # of chars as
input?
That would
On Tue Jul 31 12:21 PM, Anthony Ferrara wrote:
Jonathan,
Again, implementing something in the core that's not verified and
can't be implemented well by the vast majority of developers out
there.
Alright so I found some people supporting my claims:
On Wed Jun 27 12:32 PM, Arvids Godjuks wrote:
because at the moment i do not understand how salt stored in the hash itself
makes hash more
secure than an unsalted one.
a) In terms of 'effort' to break many passwords, there's a benefit to the salt
stored in the hash itself.
It's not 'more
On Thu Jul 12 02:34 PM, Anthony Ferrara wrote:
https://wiki.php.net/rfc/password_hash
-- password_hash()
password_hash_rfc(string $password, int $algo, array $options = array())
My personal opinion is the api should be:
password_hash(string $password, string $secret = '', array $options =
Say you have:
define('MY_HASHING_SECRET', 'hhtrg54~%$%4long'); $password =
'1234';
password_hash_rfc($password . MY_HASHING_SECRET,
PASSWORD_METHOD_BCRYPT); password_hash($password, MY_HASHING_SECRET);
Note here that in both cases we let crypt() generate a random salt that
is
RFC:
https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper
Thanks, I missed it...
I strongly disagree with this, the 'pepper' IMHO is a best practice for web
applications.
I prefer to live with the idea that an attacker may comprise some
database(s) in the 'cloud' but
On Tue Jul 31 10:54 AM, Anthony Ferrara wrote:
On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron HYPERLINK
I strongly disagree with this, the 'pepper' IMHO is a best practice
for web applications.
Again, I have not seen this being said by any security or cryptography
expert
On Mon Jun 18 07:14 PM, Anthony Ferrara wrote:
https://wiki.php.net/rfc/hash_pbkdf2
I like this proposal, it could be useful to add a simpler api that has
defaults matching the NIST recommendation:
hash_password($password, $salt, $algo = 'sha1', $iterations = 1000);
if the salt doesn't
On Fri Nov 11 12:13 AM, Stas Malyshev wrote:
- MODE_DEBUG: This one can work together with the other two,
allowing a validation of class/interface/trait presence in the file.
Basically,
it requires the file and then checks if the item exists in scope.
Not sure debug adds much here -
On Wed Nov 9 10:01 PM, guilhermebla...@gmail.com wrote:
Some would simply say he only did that because he got 3 proposals
rejected. Others would say he is pressuring A to be in PHP. But not.
I learned the hard way and multiple times to hear a big NO. But at the
same time, I earn my salary
Bring improvements to serialize() and unserialize() -- a consistent
serialize_text() which does change based on config + no more NULL bytes.
Possible improvements to PDO and stream related enhancements.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Thu Nov 3 03:06 PM, Will Fitch wrote:
Wouldn't you consider spl_autoload_register an interoperability
solution? Only your defined autoloading function would then need to
know how your file system is structured, there'd be no need for
include_path declarations and you wouldn't have to
On Sat Oct 22 04:38 AM, Nathan Nobbe wrote:
Hi folks,
With a 5.4 release right around the corner I'd like a moment of your
time to reconsider this issue [1].
Just curious why it died on the table if several folks saw value in
it, including Stephan who I gather is the primary architect of
On Thu Nov 3 11:19 AM, Anthony Ferrara wrote:
But that's besides the point. I just want to emphasize the point that
performance should not be a criteria for justifying it going into the
core...
There also seems to be the perception among some php devs that autoloading
is now the
On Sat Oct 22 10:25 AM, Anthony Ferrara wrote:
Well, I have a few opinions on this that I think are worth sharing:
1. If this change is made, we no longer would have mixins, but would
have regular multiple-inheritance (With all the issues associated
with it). Note that I said mixins and
On Sun Oct 16 06:59 PM, Stas Malyshev wrote:
It definitely makes PHP worse by propagating inconsistent APIs.
I created a patch against 5.4:
https://bugs.php.net/patch-display.php?bug_id=55475patch=is_a_5.4_alternati
verevision=latest
The patch changes the behavior to:
is_a(ab, b) // false
On Wed Sep 21 09:57 AM, Matthew Weier O'Phinney wrote:
It then reverts is_a() back to the previous behavior, and clarifies
the documentation.
To respect the release RFC, we shouldn't introduce a new BC break
(breaking behavior with something already released).
That's just a
On Wed Aug 24 08:42 AM, Pierre Joye wrote:
Hi Alan,
the breakage is about is_a with a string as 1st argument, not is_a as
a whole. So yes, it breaks is_a alone is used as validation.
I've been digging more into this:
On Thu Aug 4 09:54 PM, Raymond Irving wrote:
Hello,
I came across this little library called TameJS (http://tamejs.org/)
and fell in love with the it's syntax. This had me thinking if it was
possible to add such features to a PHP CLI (or web app):
Thanks for sharing, never heard of
On Fri Aug 19 03:48 AM, Kingsquare.nl - Robin Speekenbrink wrote:
Also the proposed include it - read the data - convert on write if
in previous format (possibly an ini setting?) would provide full BC
and would allow a painless upgrade... wouldnt it?
100% against enabling it by default.
On Wed Aug 3 05:16 PM, Lester Caine wrote:
Jan Dolecek wrote:
I was waiting for this for a while! I wrote a blog post how to get
best benefits from weak references:
http://blog.juzna.cz/2011/08/weak-references-in-php/
Perhaps this will help showing people what are they good for.
Or
On Fri Jul 22 11:17 AM, Alex Howansky wrote:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo in foo::bar\n;
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo in
On Fri Jul 22 01:46 PM, Alex Howansky wrote:
Sure, but in this case, I created the conflict intentionally because I
*want* to override it, and I'm not allowed to like I am with methods.
Don't you think that's inconsistent?
Agree
The short answer is it's not a bug but maybe an
On Wed Jun 22 11:25 AM, Reindl Harald wrote:
and php as primary web-language is missing UTF8 support in the core
You have a valid point.
Now onto foreach() for strings, any other opinions?
Seems like the discussion is closed and most likely should move to a RFC
with some consideration about
On Mon Jun 20 09:11 AM, Lee davis wrote:
Could we also use current(), next() and key() for iteration of strings?
$string = 'string';
while ($char = current($string))
{
echo key($string) // Would output the offset position I assume 0,1,2
etc??
echo $char // outputs each letter
On Tue May 10 11:07 AM, guilhermebla...@gmail.com wrote:
I'm not putting traits support inclusion on risk. I'm a string +1 to
it.
All I want is that you stop giving stupid arguments to be against the
patch instead of giving *real* relevant arguments.
Complexity:
On Mon May 9 07:29 PM, guilhermebla...@gmail.com wrote:
Hi Andi,
Sorry, but I mentioned on other thread that RFC is outdated.
I just finished an update to it bringing to recent implementation. The
idea is to get the big picture here, I may have left from previous
RFC, but if I did that,
On Wed Apr 20 04:41 PM, D. Dante Lorenso wrote:
My proposal was called filled since it was the opposite of empty
which already existed. I extended the function to return the first
non-empty value or null if all values evaluated as empty.
You could use the function like this:
$x =
On Wed Apr 20 10:55 AM, Mark wrote:
function varset($arr, $key, $default = '') { return (isset($arr[$key])
? $arr[$key] : $default); }
where the call would be:
$var = varset($_GET, 'var');
I personally like both ways...
My proposal is to make this function a core php function in PHP
On Wed Mar 30 09:05 AM, Hannes Landeholm wrote:
var_dump(\substr(foo, 5, 6) == , (string) false, false == );
Welcome to PHP. To be honest this criticism pretty much falls in the
from person that comes from another language X and is annoyed that
every little detail isn't exactly the
On Sun Feb 13 05:15 AM, André Rømcke wrote:
I have now made an RFC based on the most recent discussions:
http://wiki.php.net/rfc/traitsmodifications
I think it would sometimes be desirable to allow this, for instance
when a trait has been updated in a framework to adapt to what has
On Thu Feb 10 12:25 PM, Ben Schmidt wrote:
http://wiki.php.net/rfc/traitsmodifications
Some thoughts:
a) Class method conflict with trait
Class implementation always wins I feel is the right way to think about
traits.
But 'abstract' already has special meaning, so maybe a keyword like
On Sat Jan 8 06:33 AM, Ben Schmidt wrote:
Creating a patch will help getting feedback about what you're
proposing http://ca3.php.net/reST/php-src/README.MAILINGLIST_RULES
I hope I haven't broken any of the mailing list rules, but my
apologies if I have, and please point out
On Sun Jan 2 07:16 AM, Ben Schmidt wrote:
I would also like to propose some extensions to the functionality as
currently described, which I think could potentially add tremendous
power to the mechanism, with relatively little additional conceptual
complexity and implementation effort. I've
On Mon Dec 20 06:21 PM, Stefan Marr wrote:
= Handling of Properties/State =
This property handling was implemented in
[[http://svn.php.net/viewvc?view=revisionrevision=306476|SVN revision
306476]] and examples are given in the test cases.
+1
The E_STRICT warning seems to
On Sat Dec 18 10:29 AM, Stefan Marr wrote:
At least I do not find an argument for either way that completely
convinces me.
At the moment, the main reason is that 'public' can be considered to
be the default visibility modifier.
Based on the semantics of 'var' and dynamic properties.
Thus,
On Sat Dec 18 12:33 PM, Stefan Marr wrote:
Hi Jonathan:
On 18 Dec 2010, at 18:14, Jonathan Bond-Caron wrote:
Does the order of the declaration matter?
No, the order does not matter, and that is one of the key points of
traits compared to mixins or Python's way of multiple inheritance
On Sat Dec 11 10:25 AM, Stefan Marr wrote:
http://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_impleme
nt_interface
Are there any objections to implementing this?
It's not a bad idea, though I haven't found a strong need for it in the way
I plan to use traits.
It also
On Sun Dec 5 12:44 PM, Benjamin Eberlei wrote:
1. Just create a DateTimeValue object that is immutable, not
optimizing PHP to handle it with efficient garbage collection.
2. One step further, add a static class DateTimeValue like syntax
that creates an immutable class.
Any ideas?
Some
On Thu Dec 2 02:11 AM, Larry Garfield wrote:
See, here's the fundamental problem we're running into. There's three
different definitions of what a property is that we keep bouncing
between, each of which will dictate both syntax and semantics:
1) Properties are a smart masking layer
On Tue Nov 30 03:26 AM, Julien Pauli wrote:
I guess serialize mechanism cant use any char that can be part of a
PHP variable. And _ can. As property names respect binary
compatibility, the only char that can be used to mark private
properties is actually the NULL byte. Ping me if I'm wrong.
On Mon Nov 29 09:27 AM, Stas Malyshev wrote:
Hi!
Nice RFC, just an idea for an alternative syntax (added to the RFC
as
#2):
property Hours {
get { return $this-seconds / 3600; }
set { $this-seconds = $value * 3600; } // The variable $value
holds
the incoming value to be
On Thu Nov 25 12:47 PM, Andi Gutmans wrote:
I know there have been some high-end apps that have benefited from
some custom serializers, etc... (typically platform dependent).
I wonder if people here think improvements in these areas would move
the needle for the majority of mainstream apps
On Thu Nov 18 08:34 AM, guilhermebla...@gmail.com wrote:
Hi Larry,
For existent project examples and usage, here are 2 links of the
upcoming versions of Doctrine 2 and Symfony 2:
http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic-
On Fri Nov 5 12:57 AM, Stanley Sufficool wrote:
And why is PHP client library using latin1 for data that just isn't
latin1? That's just asking for problems...
Theoretically I could ask for UTF8, but then I don't want to have to
run utf8_decode/utf8_encode on all query strings,
On Fri Sep 17 03:13 PM, Ralph Schindler wrote:
Inline response:
On 9/17/10 1:57 PM, Jonathan Bond-Caron wrote:
On Fri Sep 17 01:06 PM, Guilherme Blanco wrote:
Another good example is to map your persistence data into your
Entities. Doctrine 2 implements this and I think that way you
On Fri Sep 17 01:06 PM, Guilherme Blanco wrote:
Another good example is to map your persistence data into your
Entities. Doctrine 2 implements this and I think that way you can
compare easily with the PHP code alternative. I'd like to ask you to
compate the same Entity mapped through
-1 for the proposed Annotations concept and associated syntax
+1 for adding APIs to parse doc blocks, minor note: should not be not called
getAnnotations
On Thu Sep 16 01:01 PM, Lars Schultz wrote:
+1 for adding APIs to parse doc blocks
-1 for introducing a new Annotations concept and
On Thu Sep 16 02:44 PM, Stas Malyshev wrote:
WTF is Annotations? We didn't define it yet. Should PHP support
http://en.wikipedia.org/wiki/.NET_metadata
http://blogs.msdn.com/b/efdesign/archive/2010/03/30/data-annotations-in-the-entity-framework-and-code-first.aspx
.NET calls this attributes
On Wed Sep 15 12:17 PM, Guilherme Blanco wrote:
I think meta programming is not and would never be part of comment.
As previously said, docblock means documentation, without any meaning
to parser, entirely human readable and totally removable without
affecting overall execution.
I have to
On Tue Sep 14 01:25 PM, Nate Abele wrote:
Sorry, but I don't see how this is even remotely close to being
appropriate for PHP. Maybe I'm missing something. :-)
I agree, the use cases are just not there
Though maybe some form of annotations could be useful in php as a
pluggable type:
On Fri Aug 20 06:54 AM, Jean-Sébastien H. wrote:
No it's wrong.
A Child is a Parent so we must be able to pass a Parent to the method
equals() defined on Child.
The declaration of the parent functions must always be valid in the
children.
Maybe my OO theory is wrong but I was under
On Fri Aug 20 08:24 AM, Nathan Rixham wrote:
Jonathan Bond-Caron wrote:
On Fri Aug 20 06:54 AM, Jean-Sébastien H. wrote:
No it's wrong.
A Child is a Parent so we must be able to pass a Parent to the
method
equals() defined on Child.
The declaration of the parent functions must
On Fri Aug 20 09:10 AM, Jonathan Bond-Caron wrote:
Maybe Stas can comment but I can't reproduce the E_STRICT warning Is
this php HEAD?
class ObjParent {
function set($param2 = '') {}
}
class ObjChild extends ObjParent {
function set(){ echo .; }
}
My mistake
On Tue Aug 10 07:42 PM, Josh Davis wrote:
Derick's point was about consistency. The approach described in his
mail is consistent with current syntax and mechanism(s). Current
typehints do not apply any kind of conversion, so treating scalar
hints the same way is consistent with the current
I've starting playing around with the zend engine,
is there any hope / plans for better interoperability with how
zend_compile_file() should be extended?
The goal being to reduce the amount of X is not compatible with Y.
It would be possible to separate extensions in two categories and
On Wed Jun 16 07:04 AM, Ilia Alshanetsky wrote:
drop the Sqlite2 extensions from Trunk as they are superseded by
the
Sqlite3
extensions. The sqlite2 library is no longer maintainer and the
migration path from version 2 to 3 is very simple. Unless there
any objections, I'd like to
On Thu May 27 11:22 AM, David Soria Parra wrote:
On 2010-05-27, Zeev Suraski z...@zend.com wrote:
+1 from me for this. I think two solutions is not the right way and we
+should
try to make the type system consistent for the user. Therefore +1 for
auto-converting.
I still feel the debate of
On Mon Apr 12 05:16 AM, Stefan Marr wrote:
On 12 Apr 2010, at 10:39, Lukas Kahwe Smith wrote:
On 12.04.2010, at 10:34, Derick Rethans wrote:
Hi!
But just as a quick response, without aliasing, there would be no way
to use a conflicting method from a trait.
On first sight, that is not
On Wed Mar 24 06:50 AM, Lukas Kahwe Smith wrote:
Ahoi,
Thought it would be better to open up a new thread and also using the
term horizontal reuse in the subject so that we make it clearer that
there are actually two approaches. Here is the URL for Stefan's
proposal:
On Wed Mar 24 06:50 AM, Lukas Kahwe Smith wrote:
The third sentence is not so clear to me, but if I guess it its also
just a typo as it makes more sense to me when replacing renaming to
result in renaming. But maybe you could tweak that paragraph to be a
bit clearer. For example its still
On Wed Oct 14 04:07 PM, Lukas Kahwe Smith wrote:
On 14.10.2009, at 22:03, Stanislav Malyshev wrote:
Hi!
So lets warm this up again.
HEAD is for development .. so lets get this into HEAD so that it
will be part of the next bigger PHP release for sure!
Well, the code is sitting
On Thu Jul 2 08:53 AM, Paul Biggar wrote:
On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetskyi...@ilia.ws wrote:
On 2-Jul-09, at 4:45 AM, Paul Biggar wrote:
I think you might not have read what I suggested (it is different
than the one I emailed to you privately). What you want is fully
On Mon Mar 2 11:10 PM, Andi Gutmans wrote:
I don't see a fundamental issue why it could not be arbitrary.
The only challenge which may be an issue is that this code clearly
allocates the buffer on the stack for what are probably performance
reasons. If you allow arbitrary chunk size and use
Hi everyone, I have a question about streams and the maximum chunk size of
8192.
Ive read README.STREAMS and found these slides by Wez:
http://netevil.org/blog/2008/07/slides-php-streams
While trying to write an Amazon S3 stream wrapper and I ran into an issue
with large files:
On Sat Dec 6 12:09 AM, Lester Caine wrote:
Derick Rethans wrote:
( Slipping a date through DateTime and returning it DATE_W3C seems
to
be adding the correct daylight saving details so far and allowing
ADOdb date to work )
This is not the correct thing to do, as you will lose timezone
On Wed Nov 12 02:14 PM, Lukas Kahwe Smith wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
I) enable ext/hash by default
+1
II) remove ext/mhash
0
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/
+1
3) resource constants (choose one)
c
Hi Everyone,
I've started a new RFC about PHP and mixins:
http://wiki.php.net/rfc/mixin
Stefan has done some really interesting research with traits though I'm
concerned about how intuitive it is.
Good summary of how mixins and traits deal with conflict here:
On Thu Aug 28 01:47 PM, Christian Seiler wrote:
Hi again,
A few weeks ago I wrote quite a long posting to internals@ that tried
to clarify the situation on the round() function in PHP. I was asked
to write it up as an RFC in the wiki, which I have done:
http://wiki.php.net/rfc/rounding
On Mon Aug 25 06:28 PM, steve wrote:
Has anyone had success compiling PHP with LLVM?
I haven't tried it, here is a good summary:
http://llvm.org/devmtg/2008-08/Lopes_PHP-JIT-InTwoDays.pdf
In short, it is 'slower' but that seems to be without any caching of the
bytecode
Bytecode is not
It's a big +1 for me and this sums it up
PHP is about building on the knowledge and experience of the typical
target user. This target user changes slowly as we all get older and
the industry we are in changes and we need to recognize that and adapt
the language appropriately. What is
+1 here
A summary:
PHP6 MUST not allow setting magic quotes
PHP6 MUST trigger a fatal error when attempting to set magic quotes (php.ini
or set_magic_quotes_runtime())
PHP6 MUST allow getting magic quotes info (always false)
PHP5.3 MUST allow setting magic quotes
PHP5.3 MUST trigger an
BC break. However, perhaps the perfect shouldn't be the enemy of
the good and we shouldn't let the inability to fix floats as
array indices be a reason not to improve ==.
- Todd
On Fri, 2008-05-02 at 19:04 +0200, Pierre Joye wrote:
On Fri, May 2, 2008 at 6:52 PM, Jonathan Bond-Caron [EMAIL
);// 0,3
// expected: 0,3
echo \n;
I'll dig more into the code... just thought I would share this (PHP 5.2.3)
-Original Message-
From: Stefan Walk [mailto:[EMAIL PROTECTED]
Sent: May 4, 2008 1:31 PM
To: Jonathan Bond-Caron
Cc: internals
Hi,
I'm new to the PHP internals list and I'm posting an issue I'm sure has been
mentioned before -- float comparison
I'd like to know if there are reasons not to change the default behavior
when comparing floats.
i.e. This would seem logical to me:
$test =
' thing.
We get '1960', then converting back to a float, all accuracy bits are 0, so
(numeric)$test == (double)1960
I would guess adding a new type is a big amount work?
-Original Message-
From: Pierre Joye [mailto:[EMAIL PROTECTED]
Sent: May 2, 2008 1:05 PM
To: Jonathan Bond-Caron
Cc
76 matches
Mail list logo
