[RFC] deprecate md5_file and sha1_file View as Markdown

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 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 sha1_file(). This will
make people think about upgrading to a better alternative. If you still
need this functionality you can always switch to the hash_file() function.

Carrying around these two dedicated functions seems a bit too much for a
modern PHP. What do you think?

My feeling was that this is a no brainer. Should I open an RFC for this?

Kind regards,

Tom Van Looy

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 your choice when developing new
applications.

I suggest to deprecated the functions md5_file() and sha1_file(). This will
make people think about upgrading to a better alternative. If you still
need this functionality you can always switch to the hash_file() function.

Carrying around these two dedicated functions seems a bit too much for a
modern PHP. What do you think?

My feeling was that this is a no brainer. Should I open an RFC for this?

Kind regards,

Tom Van Looy

I feel that if we deprecate the file versions of these algorithms we
probably should
also deprecate the ones which work with plain old strings, namely md5() and
sha1(). [1] [2]

It should be noted that these hash functions would still be available
through the
Hash extension which is always available as of PHP 7.4 as it became a core
extension.

Depending on how controversial these deprecations are they could be bundled
with the big deprecation RFC for PHP 8.0, which is currently in draft. [3]

George P. Banyard

[1] https://www.php.net/manual/en/function.md5.php
[2] https://www.php.net/manual/en/function.sha1.php
[3] https://wiki.php.net/rfc/deprecations_php_8_0

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.

If people are using the existing md5 / sha1 algorithms, chances are it's
because they're actually wanting to get a hash to compare to something
that has already been stored.

There's not much point in deprecating the algorithm if we don't
eventually plan to remove it, and there is an exactly zero percent
chance of it being removed at any point in the next 50 years.

Mark Randall

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
structure their code better. Deprecation is usually for functions that
are unsupported (and going to go away) or not having any non-broken uses
anymore. We have crc32() function which is much less secure than md5 for
check-summing obviously, and we don't deprecate it because of that. I
don't think we should use deprecations for that purpose.

Carrying around these two dedicated functions seems a bit too much for a
modern PHP. What do you think?

There's zero effort expended on "carrying around" these functions, and I
don't see why it's "too much" for "modern PHP"? What changed in "modern
PHP" that suddenly brought forward the need to minimize the number of
existing functions? I don't see any reason for that.
On the contrary, deprecating it causes work for people that legitimately
use these functions, and makes them either turn off deprecation warnings
(unsafe and may lead to real deprecations pass unnoticed) or work around
this. I don't think it is beneficial.

--
Stas Malyshev
smalyshev@gmail.com

As others have mentioned, this will do nothing but make people annoyed
and switch to the hash_file() version of exactly the same thing or put
up another hurdle to updgrading PHP.

The password hashing API now provides an obvious go-to for password hashing.

For other hashing usages there are, I think, basically two scenarios
developers find themselves in:

1. I'm using an API or some other external service and that requires the
   use of md5 / sha1 - I don't have a choice

2. What do I use instead? Internet searches return "sha1 / md5 is fine
   for this purpose" or recommend algorithms that aren't natively supported
   in PHP.

The (hash library) documentation does nothing towards helping developers
decide what algorithms (or even which hash library functions) they
should use for what purposes (and there are a lot of acronyms that many
developers are likely to have never encountered that are never explained

• HMAC, PBKDF2, HKDF).

Yes, of course developers can use third party sources to supplement the
information in the manual, but who has time to go seartching for that
(esp. when most of the first page on Google probably tells you md5/sha1
is fine anyway)?

If you want to change the way developers think about hashing when
writing PHP, I would start with the documentation rather than
deprecating functions which are essentially aliases and are highly
likely used all over the place in cases where they do exactly what
people want.

AllenJB

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 sha1_file(). This will
make people think about upgrading to a better alternative. If you still
need this functionality you can always switch to the hash_file() function.

Carrying around these two dedicated functions seems a bit too much for a
modern PHP. What do you think?

My feeling was that this is a no brainer. Should I open an RFC for this?

Kind regards,

Tom Van Looy

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.

If people are using the existing md5 / sha1 algorithms, chances are it's
because they're actually wanting to get a hash to compare to something
that has already been stored.

There's not much point in deprecating the algorithm if we don't
eventually plan to remove it, and there is an exactly zero percent
chance of it being removed at any point in the next 50 years.

Mark Randall

--

Why? What does deprecating those two functions do to make PHP a better
language? It doesn't add any new features. It doesn't fix any security
issues. It doesn't even take away the ability to perform the functionality
that they provide, since it still exists in the hash_file function.

If you don't like the function, then don't use it.

I'd be fine with someone just adding a Warning to the documentation that
MD5 and SHA-1 are known broken hashing algorithms when used for
cryptographic/security purposes. The algorithms and related functions
are completely fine though for other purposes such as detecting
single-bit changes in file data where something a little more robust
than CRC32 is needed but don't want to waste a lot of storage space.
md5() and sha1() already have basic warnings applied.

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/