This guide explains how to compute and verify the cryptographic hashes required for software articles in Biochemoinfo Journal. It is referenced from both the Open-Source and the Commercial software author guidelines.
A repository link or download URL guarantees nothing about which version of the software a future reader will encounter. A hash is a cryptographic fingerprint — it lets any reader, on any computer, in any year, confirm that the file they have is byte-for-byte identical to the version reviewed at submission. It is the difference between a citation and a verifiable citation.
1. SHA-256 vs. SHA-512 vs. MD5 vs. SHA-1
- SHA-256: The journal's default. Strong, widely supported, fast on modern CPUs. Required for all archive files.
- SHA-512: Acceptable substitute for SHA-256 when archives are very large (>5 GB) or when using systems that produce SHA-512 by default. Stronger but unnecessary for most cases.
- SHA-1: Acceptable only as a Git commit hash, because Git itself uses SHA-1 internally for legacy repositories. Not acceptable for archive verification.
- MD5: Not accepted for any verification purpose. MD5 is cryptographically broken.
2. Computing a Git Commit Hash
To get the commit hash of the version you want to publish:
If your repository is using SHA-256 mode (Git 2.29+):
It is good practice to also create a signed tag for the published version:
3. Computing a SHA-256 Hash of an Archive
LinuxmacOS
For SHA-512:
Windows (PowerShell)
Windows (Command Prompt)
4. Depositing in Zenodo
- Sign in at zenodo.org. ORCID sign-in recommended.
- If your code is on GitHub, enable the GitHub–Zenodo integration: every release tag automatically creates a Zenodo deposit with its own DOI. Documentation: GitHub citation docs.
- Otherwise, click New Upload, attach the
.tar.gzor.ziparchive, fill in metadata (title, authors, version, license), and publish. You will receive a permanent DOI. - After the deposit is published, compute the SHA-256 of the file you uploaded and confirm that Zenodo displays the matching MD5/SHA in its file metadata. The SHA-256 you put in the paper must match the hash of the file present in Zenodo.
5. Depositing in Software Heritage
- Visit archive.softwareheritage.org/save.
- Enter your repository URL (Git, Mercurial, or SVN supported).
- Click Save Code Now. The archive will crawl the repository, typically within minutes for small projects.
- Once archived, retrieve the SWHID (Software Heritage Identifier) for your specific revision.
A SWHID for a release looks like
swh:1:rel:abc123def456.... - Include this SWHID in the Verification Block in your paper.
6. Archiving Documentation Pages (Tier 3 only)
For commercial software, the paper must also reference archived snapshots of the product's documentation pages.
- Wayback Machine: web.archive.org/save — paste each documentation URL and click Save Page Now.
- archive.today: archive.today — captures dynamic pages that the Wayback Machine sometimes misses.
Capture, at a minimum: the homepage, the technical documentation, the pricing/licensing page, and any feature description page that is referenced in your paper.
7. Common Pitfalls
Hash mismatch after re-uploading
Don't re-create the archive after computing the hash. If you compute a hash for v1.0.0.tar.gz,
then re-tar the directory (even with no content change), the new file will have a different hash because
tarballs include timestamps and file ordering metadata. Compute the hash of the exact file you upload,
and don't recreate it afterwards.
Line-ending differences (Windows vs. Linux)
If your archive contains source files with mixed CRLF/LF line endings, building on different platforms can produce
different binaries. For Tier 1 reproducibility, configure .gitattributes with explicit line-ending rules:
Forgetting to publish the Zenodo deposit
Zenodo allows draft uploads. A draft does not have a public DOI and cannot be cited. After uploading, make sure you click Publish — not just Save.
Reproducible builds (advanced)
For maximum integrity, advanced authors may want their builds to be byte-identical when reproduced from source. This is the Reproducible Builds standard. It is not required by Biochemoinfo Journal, but is recommended for high-impact tools where long-term auditability matters.
8. Verifying Someone Else's Software (For Readers)
If you want to verify a paper's software:
- Find the Verification Block in the paper.
- Download the archive from the Zenodo DOI listed.
- Run the platform-appropriate hash command above.
- Compare the output to the SHA-256 in the Verification Block. They must match exactly.
If they do not match, the file has been altered, corrupted, or replaced. Contact the journal at info@biochemoinfojournal.com with details.
9. Where Does This Sit in the Submission Workflow?
- Finalize the version of your software you intend to publish.
- Tag it in Git (
git tag v1.0.0) and push. - Create the release archive (
.tar.gzor.zip). - Compute the SHA-256 of the archive.
- Upload the archive to Zenodo → obtain DOI.
- Trigger Software Heritage to archive the repository → obtain SWHID.
- Tier 3 only: Capture documentation snapshots in Wayback Machine and archive.today.
- Insert all identifiers and hashes into the Verification Block in the paper.
- Submit the paper to the journal.
Questions about hashes, archives, or verification? info@biochemoinfojournal.com.