On 25 July 2024 23:54:53 BST, Nick Lockheart wrote:
>Doesn't password_hash() handle this automatically? The result of the
>password_hash() function includes the hash and the algorithm used to
>hash it. That way password_verify() magically works with the string
>that came from password_hash().
On Thu, Jul 25, 2024 at 8:33 AM Tim Düsterhus wrote:
> No, we are talking about end users who are following tutorials that were
> written when PHP 4 was the most recent PHP version.
>
> We are also talking about end users who look at existing code bases for
> "inspiration", see md5() used, notice
On Fri, 2024-07-26 at 00:44 +0200, Juliette Reinders Folmer wrote:
> On 26-7-2024 0:00, Nick Lockheart wrote:
>
> >
> > That's a good point. What if there were crypto functions that
> > worked
> > like password_hash() in that they had one generic function name,
> > but
> > magically used the new
On 26-7-2024 0:00, Nick Lockheart wrote:
That's a good point. What if there were crypto functions that worked
like password_hash() in that they had one generic function name, but
magically used the new/better "best practice" algorithms as time went
by without the need to update any calling code?
>
> On Jul 25, 2024 at 6:02 PM, mailto:li...@ageofdream.com)>
> wrote:
>That's a good point. What if there were crypto functions that worked
>
>
> like password_hash() in that they had one generic function name, but
> magically used the new/better "best
>
> On Jul 25, 2024 at 5:35 PM, (mailto:imsop@rwec.co.uk)> wrote:
>Rather than force people to use functions that we acknowledge are hard
>
>
> to use, surely the logical thing is to make the "right" code *easy* to use?
> Which means if we want people to use SHA-
On Thu, 2024-07-25 at 22:34 +0100, Rowan Tommins [IMSoP] wrote:
> On 24/07/2024 23:01, Morgan wrote:
> > And they would still be available as hash("md5") and hash("sha1");
> > the
> > only reason they're called out as their own distinct functions
> > today
> > is historical inertia.
>
>
> I do
On 24/07/2024 23:01, Morgan wrote:
And they would still be available as hash("md5") and hash("sha1"); the
only reason they're called out as their own distinct functions today
is historical inertia.
I don't agree that the reasons for including standalone functions are
"historical". The RFC i
Hi
On 7/25/24 19:28, Nick Lockheart wrote:
I'm in the process of refactoring an old framework and I just found a
use of sha1(). It's being used to generate a unique resource lock. It
doesn't need to be secure, just a fast and random UID.
SHA-1 is a deterministic algorithm, thus it is unable to
On Thu, 2024-07-25 at 17:33 +0200, Tim Düsterhus wrote:
>
> As an example, using md5_file() to implement a cache buster is fine,
> but a less-experienced developer may believe that md5_file() uniquely
> identifies the file contents and use it in a way where strong
> collision-resistance against a
Hi
On 7/25/24 17:40, Arnaud Le Blanc wrote:
Thank you! We have updated the RFC accordingly.
LGTM :-)
5. In the explanation of
"ReflectionClass::markLazyObjectAsInitialized()", it says:
Its behavior is the same as described for Ghost Objects in the
Initialization Sequence section, except th
Hi Tim,
On Thu, Jul 25, 2024 at 4:47 PM Tim Düsterhus wrote:
> I'm seeing there are some more changes and not just to the cloning
> section. I've went through the entire RFC once again and here are my
> (hopefully final) five remarks. They are only about textual
> clarification of some behaviors,
Hi
On 7/24/24 05:58, Peter Stalman wrote:
is already quite specific. We're talking about end users who are rolling
their own security implementations and are unaware of the security risks
but somehow know how to use these functions without reading the
documentation and warnings.
No, we are tal
Hi
On 7/24/24 17:23, Nicolas Grekas wrote:
Cloning has kept us busy in the last days and after many brainstorming
sessions, we've decided to follow your initial proposal : make the clone
operator trigger the initialization of the original object before cloning
it.
Thank you. That cloning behav
14 matches
Mail list logo
