Native SHA-256 checksum support and SHA-1 deprecation

[Andrés Restrepo]

Hi Arno,

jDownloads 4.1.6 currently generates MD5 and SHA-1 checksums automatically when a file is uploaded or replaced.

Could you please consider adding native SHA-256 checksum support in a future jDownloads release, preferably also in Series 6?

NIST recommends transitioning away from SHA-1 in favor of SHA-2 or SHA-3, with SHA-256 recommended as a minimum for interoperable applications:

https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions

A possible implementation could include:

* A dedicated `sha256_value` database field.
* Automatic calculation using `hash_file('sha256', $filePath)`.
* Calculation during backend uploads, file replacements, monitoring scans, scan-worker processing and referenced-file assignments.
* Native `{sha256_title}` and `{sha256_value}` placeholders.
* SHA-256 availability in both the Download Details and Summary layouts.
* An option to calculate SHA-256 values for existing downloads.
* Gradual deprecation of SHA-1 while retaining temporary backward compatibility.

I would not suggest storing SHA-256 in the existing `sha1_value` field because that would make the database field, backend label and layout placeholders misleading.

I currently publish SHA-256 through a Joomla custom field and a Summary template override, but native support would keep the checksum synchronized automatically whenever the downloadable file is replaced.

Thank you for considering this improvement.

[Arno]

Hi Andrés, 
thank you for the excellent and very well-structured suggestion.

We have now implemented this for jDownloads 6.x (development branch), exactly as you proposed:
1. New dedicated database field: `sha256_value`
2. Automatic SHA-256 calculation on upload/replacement
3. SHA-256 handling integrated in scan and scan-worker flows
4. Native placeholders supported: `{sha256_title}` and `{sha256_value}`
5. Output available in Download Details and Summary layouts
6. Existing MD5/SHA-1 support remains for backward compatibility

So yes: this is now on our v6 track. 
For 4.x we currently keep behavior stable and unchanged.

Thanks again for pushing this topic with clear technical rationale and references.