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.
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.