On Tue, 11 Feb 2020, 06:59 Stanislav Malyshev, wrote:
> Hi!
>
> > I suggest to deprecated the functions md5_file() and sha1_file(). This
> will
>
> Not sure what's the point of it. SHA1 and MD5 didn't change. The
> recommendations for their usage has changed, but we generally don't use
>
Hi!
> the hash_file() function still supports md5 and sha1 so people that need it
> should then migrate to hash_file('md5', ...) or hash_file('sha1', ...)
> instead. That was the idea
This means spending time and effort to cause extra work to people that
already have working code with existing
Hi!
> I suggest to deprecated the functions md5_file() and sha1_file(). This will
Not sure what's the point of it. SHA1 and MD5 didn't change. The
recommendations for their usage has changed, but we generally don't use
deprecation warnings to improve users' code and recommend them how to
On Mon, 10 Feb 2020, 23:36 Mark Randall, wrote:
> On 10/02/2020 21:49, Tom Van Looy via internals wrote:
> > I suggest to deprecated the functions md5_file() and sha1_file(). This
> will
> > make people think about upgrading to a better alternative.
>
> It won't.
>
You can lead a horse to water
On 10 February 2020 21:52:42 GMT, j adams wrote:
>I disagree. While MD5 and SHA1 might not be suitable for modern
>cryptographic operations, these functions might be needed for legacy
>situations -- e.g., munging through old data.
>
>
>On Mon, Feb 10, 2020 at 1:50 PM Tom Van Looy via internals <
On Mon, Feb 10, 2020 at 5:36 PM Mark Randall wrote:
> On 10/02/2020 21:49, Tom Van Looy via internals wrote:
> > I suggest to deprecated the functions md5_file() and sha1_file(). This
> will
> > make people think about upgrading to a better alternative.
>
> It won't.
>
> At best it will make
On 10/02/2020 21:49, Tom Van Looy via internals wrote:
I suggest to deprecated the functions md5_file() and sha1_file(). This will
make people think about upgrading to a better alternative.
It won't.
At best it will make people switch to the hash function. At worst people
will not upgrade.
On Mon, 10 Feb 2020 at 22:50, Tom Van Looy via internals <
internals@lists.php.net> wrote:
> Hi
>
> While in some environments the use of MD5 and SHA1 are still acceptable for
> some use cases like file integrity verification etc. the use of these
> algorithms should be discouraged and not be
the hash_file() function still supports md5 and sha1 so people that need it
should then migrate to hash_file('md5', ...) or hash_file('sha1', ...)
instead. That was the idea
Kind regards,
Tom
On Mon, Feb 10, 2020 at 10:52 PM j adams wrote:
> I disagree. While MD5 and SHA1 might not be
I disagree. While MD5 and SHA1 might not be suitable for modern
cryptographic operations, these functions might be needed for legacy
situations -- e.g., munging through old data.
On Mon, Feb 10, 2020 at 1:50 PM Tom Van Looy via internals <
internals@lists.php.net> wrote:
> Hi
>
> While in some
Hi
While in some environments the use of MD5 and SHA1 are still acceptable for
some use cases like file integrity verification etc. the use of these
algorithms should be discouraged and not be your choice when developing new
applications.
I suggest to deprecated the functions md5_file() and
Hi,
On Mon, 2020-02-10 at 10:18 -0600, Paul M. Jones wrote:
> After a couple of years of incubation, I am happy to offer a second
> version of this RFC:
>
> https://wiki.php.net/rfc/request_response
What indication is there that this will be more successfull than the
filter API? The filter
> On Feb 10, 2020, at 11:18 AM, Paul M. Jones wrote:
>
> Hi Internals,
>
> After a couple of years of incubation, I am happy to offer a second version
> of this RFC:
>
> https://wiki.php.net/rfc/request_response
>
> It proposes an object-oriented approach around request and response
>
On 10/02/2020 16:18, Paul M. Jones wrote:
Hi Internals,
Thanks in advance for your time and consideration while evaluating it.
I suspect this is a similar sentinment to the previous version, but I
can personally see no major benefit to having this as a core extension.
I think the reality is
Hi Paul,
thanks for bringing it back. Got some questions:
1. In your RFC $_ENV is bound to $request.
Looking at HttpFoundation can see it's build from $_GET, $_POST, $_FILES,
$_COOKIE, $_SESSION
and then looking at PSR ServerSideRequest it's build from $_COOKIE, $_GET,
$_POST, $_FILES, $_SERVER
Hi Internals,
After a couple of years of incubation, I am happy to offer a second version of
this RFC:
https://wiki.php.net/rfc/request_response
It proposes an object-oriented approach around request and response
functionality already existing in PHP, in order to reduce the global-state
>
> On Feb 10, 2020 at 3:45 AM, mailto:ocram...@gmail.com)>
> wrote:
>
>
>
>
>
> For once, we would have a function with a self-describing, clear name:
>
>
>
>
Seriously?That function name reminds me of COBOL programming.
>
>
>
>
On Sun, Feb 9, 2020 at 10:33 PM Mike Schinkel wrote:
> 2. Do we really want to add a standard library function 53 characters
> long?
>
> Can we not come up with a more concise name than
> get_defined_functions_allowed_in_constant_expressions(), like maybe
> get_const_expr_funcs() or
18 matches
Mail list logo
