Verify checksums and their limits
See this course’s project requirements
A local Python release script that validates source, runs tests, packages only allowlisted files, writes checksums and stops on a failing stage.
Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.
What to include
- Create an ordered stage/gate map with explicit failure branches.
- Document the exact child command, working directory, timeout, and failure interpretation.
- Create and inspect an actual archive whose member list exactly matches the release allowlist.
- Recompute the delivered archive digest and explain integrity versus correctness/provenance.
- Demonstrate failed-test stop and byte-preserving overwrite refusal in isolated copies.
- Deliver one declared local release with stage, package, checksum, failure, and operational-limit evidence.
Review and revise
Use these criteria to check your work and choose what to improve.
- The implementation or declared simulation follows the supplied contract and retains inspectable original inputs.
- Normal, boundary and rejected cases are recorded with expected versus observed results.
- The changed case has a correct explanation and does not rely on hidden state.
- The project includes source, outputs, instructions and honest tool, privacy and verification limits.
Want more background?
The idea in everyday life
Original local greeting project: greeting.py, test-greeting.py, usage.txt, release.py and test-pipeline.py. Its release archive may contain only greeting.py and usage.txt. No external CI account, deployment, or package installation is required.
A SHA-256 digest detects a difference from a trusted expected byte sequence. A matching digest does not prove the code is correct or authenticate an untrusted manifest.
Verify checksums and their limits — original worked practice
A SHA-256 digest detects a difference from a trusted expected byte sequence. A matching digest does not prove the code is correct or authenticate an untrusted manifest.
Original local greeting project: greeting.py, test-greeting.py, usage.txt, release.py and test-pipeline.py. Its release archive may contain only greeting.py and usage.txt. No external CI account, deployment, or package installation is required.
1. Step 1
Read the archiveSHA256 value in release-manifest.json.
You should see: The manifest records a digest of the actual archive bytes.
A SHA-256 digest detects a difference from a trusted expected byte sequence. A matching digest does not prove the code is correct or authenticate an untrusted manifest.
2. Step 2
Compute hashlib.sha256(archive.read_bytes()).hexdigest() or run the supplied checksum assertion.
You should see: The recomputed digest matches the manifest.
A SHA-256 digest detects a difference from a trusted expected byte sequence. A matching digest does not prove the code is correct or authenticate an untrusted manifest.
3. Step 3
Compare an intentionally changed archive copy with the original digest without modifying the retained release.
You should see: A byte change produces a mismatch in the controlled check.
A SHA-256 digest detects a difference from a trusted expected byte sequence. A matching digest does not prove the code is correct or authenticate an untrusted manifest.
4. Step 4
Record what the digest proves and why manifest trust is separate.
You should see: A checksum verification and trust-boundary note.
A SHA-256 digest detects a difference from a trusted expected byte sequence. A matching digest does not prove the code is correct or authenticate an untrusted manifest.
What to finish
Recompute the delivered archive digest and explain integrity versus correctness/provenance.
Watch for this
Treating an untrusted matching manifest as authentication or a checksum as a correctness test.
How can I tell I understand it?
Demonstrate the rule: A SHA-256 digest detects a difference from a trusted expected byte sequence. A matching digest does not prove the code is correct or authenticate an untrusted manifest. Use the supplied variant to distinguish a changed result from a broken implementation.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
Pass the check. We’ll save the progress.
Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.
Go to the knowledge checkTools, templates, and lesson sources
Tools and templates
Tools open in a new tab so you can keep your place here.
Sources and further reading
Explore the references behind this lesson.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.