How to read signing info in developer workflows
- Step 1Grab the artifact from the PR — Download the JAR/APK attached to the PR or built by the CI job. No branch checkout or local build needed for the signing check.
- Step 2Drop it in — Open /archive-tools/archive-signing-info (Pro+), drop the single file, and let it extract and scan.
- Step 3Read manifest vs signing files — A manifest-only finding means not signed; a
Signing files: ...line means JAR-style signing is present. Treat these differently in review. - Step 4Check for the APK block — For APKs, look for "APK Signing Block detected" — that covers pure v2/v3 builds with no JAR-style files.
- Step 5Diff across builds when needed — If signing changed between versions, run Archive Diff on before/after to see which META-INF entries were added or removed.
- Step 6Gate in CI separately — Keep the authoritative check in CI:
apksigner verify --print-certsorjarsigner -verify. Read Signing Info is the human triage, not the gate.
Browser triage vs CI gate
How Read Signing Info fits a dev pipeline. Use it for the fast in-review check; keep the verifying CLI as the release gate.
| Stage | Tool | Question answered | Blocking? |
|---|---|---|---|
| PR triage | Read Signing Info (browser) | Does it carry signing artifacts? | No — informational |
| Code review note | Read Signing Info → paste JSON | Manifest-only vs signed? | No — reviewer judgment |
| Build comparison | Archive Diff | Did META-INF change? | No — diff review |
| CI release gate | apksigner verify / jarsigner -verify | Is the signature valid & by whom? | Yes — must pass |
| Supply-chain record | Checksum Generator | Is this the exact artifact? | Yes — manifest hash |
Scripting equivalents (since there is no API yet)
What each finding maps to in code. Read Signing Info wraps the detection step; these are the underlying pieces if you need to automate.
| Read Signing Info finding | Underlying check | Library / CLI |
|---|---|---|
| "Found META-INF/MANIFEST.MF" | Entry exists in the ZIP central directory | fflate unzipSync (Node) / unzip -l |
| "Signing files: *.RSA/.SF" | Filenames match META-INF/*.(RSA|DSA|EC|SF) | fflate entry listing + regex |
| "APK Signing Block detected" | APK Sig Block magic before central dir | Manual byte read / apksigner |
| "No digital signature found" | None of the above matched | n/a |
| (validity / signer — not provided) | Digest + cert chain verification | apksigner verify / jarsigner -verify |
Cookbook
Review-time scenarios with the JSON you would paste into the PR. The shape is the tool's real { filename, findings } output.
PR bumps a vendored JAR — is the new one signed?
The reviewer's question. The report shows signing files present, so the bump keeps a signed dependency. Paste it as evidence; defer validity to CI.
vendor-sdk-4.1.0-signing.json
{
"filename": "vendor-sdk-4.1.0.jar",
"findings": [
"Found META-INF/MANIFEST.MF — JAR-style archive.",
"Signing files: META-INF/SDK.SF, META-INF/SDK.RSA"
]
}
PR comment: signing files present (was also signed in 4.0.x). CI verifies validity.Build APK from CI — confirm it has a signing block
A release-flavored APK from a CI artifact. The v2/v3 block is detected, confirming the signing step ran. The actual valid/invalid verdict still comes from apksigner in the gate.
app-prod-release-signing.json
{
"filename": "app-prod-release.apk",
"findings": [
"Found META-INF/MANIFEST.MF — JAR-style archive.",
"Signing files: META-INF/CERT.SF, META-INF/CERT.RSA",
"APK Signing Block detected (Android v2/v3 signature)."
]
}Catch an accidentally unsigned debug build
Someone attached a debug APK without the release signing. The manifest is there but no signing block — a clear signal in review to ask for the right build.
app-debug-signing.json
{
"filename": "app-debug.apk",
"findings": [
"Found META-INF/MANIFEST.MF — JAR-style archive."
]
}
PR comment: this looks like a debug build — no signing block. Please attach the release APK.Compare signing across two builds
When a release suddenly fails verification downstream, diff the previous and current artifacts to see if a META-INF file went missing.
Step 1: read both → v1 has "Signing files: CERT.SF, CERT.RSA"
v2 has only "Found META-INF/MANIFEST.MF"
Step 2: Archive Diff v1 vs v2 →
- removed: META-INF/CERT.SF
- removed: META-INF/CERT.RSA
Conclusion: signing step was skipped in v2's build.Node equivalent for a CI smoke check
Since there is no JAD API, here is the underlying detection in Node with fflate — the same logic the browser tool runs, for when you want it in a script.
import { unzipSync } from 'fflate';
import { readFileSync } from 'fs';
const files = unzipSync(readFileSync('app-release.apk'));
const names = Object.keys(files);
const hasManifest = names.includes('META-INF/MANIFEST.MF');
const sigFiles = names.filter(n => /^META-INF\/.*\.(RSA|DSA|EC|SF)$/i.test(n));
console.log({ hasManifest, sigFiles });
// validity still needs: apksigner verify --print-certsEdge cases and what actually happens
Expecting a public API / CLI
Not availableRead Signing Info is a UI tool with no public API. Automate the detection with fflate + a filename regex, and gate releases with apksigner/jarsigner in CI.
Batching many artifacts
One file per runThe tool reads a single file at a time. For many archives, script the fflate equivalent or use Batch Compression Report for broad analysis.
Treating a positive finding as a passing gate
MisusePresence of a signing block is not validity. Do not let a green Read Signing Info report substitute for the CI apksigner verify gate.
Manifest-only finding on a 'signed' build
Build signalIf a build you expected to be signed reports manifest-only, the signing step likely did not run. This is a useful catch — verify the build config.
Password-protected artifact
Extraction failedThe tool passes no password to the extractor, so an encrypted archive will not extract. Decrypt in your build pipeline first.
APK with no META-INF (pure v2/v3)
SupportedModern APKs may omit JAR-style files. The APK-block magic check still detects the signature block, so the artifact is correctly flagged.
Fat JAR over the entry cap
Tier limit exceededAn uber-JAR with hundreds of thousands of classes can exceed 50,000 entries on Pro. Use a higher tier (500,000) or check a thinner artifact.
Reproducible-build timestamp worries
Not applicableRead Signing Info does not rebuild the archive — it only reads and emits a JSON report, so it never touches entry timestamps. Use Timestamp Normalizer when you actually need to rewrite an archive.
Frequently asked questions
Is there an API for CI integration?
Not yet. For automation, replicate the detection with fflate (unzipSync + a META-INF/*.(RSA|DSA|EC|SF) regex) and gate releases with apksigner verify / jarsigner -verify in your pipeline.
Can I check many JARs at once?
No — it processes one file per run. Script the fflate equivalent for bulk, or use Batch Compression Report for multi-archive analysis.
Does it verify the signature for my gate?
No. It detects signing artifacts; it never checks validity or signer. Keep apksigner/jarsigner as the authoritative CI gate.
Why use it during review at all?
Because it answers "is this even signed?" in seconds with no checkout or toolchain, and the JSON pastes cleanly into the PR. It is the fast human triage next to your automated gate.
Does it modify or rebuild my archive?
No. It only reads the archive and outputs a <name>-signing.json report. Your input is never altered or re-emitted, so reproducible-build concerns do not apply here.
How do I tell 'signed' from 'has a manifest'?
A Found META-INF/MANIFEST.MF line alone means not signed. A Signing files: ... line (or an APK Signing Block) means signing artifacts are present.
Can it tell which APK signature version is used?
No — it reports "v2/v3" generically. Use apksigner verify --verbose to see which schemes verify individually.
What if a build dropped a META-INF file?
Run Archive Diff on the previous and current artifacts to see exactly which signing entries were added or removed between builds.
Does it pass through to a server?
No. Extraction and detection run in-browser via WASM. Nothing about the artifact is uploaded — fine for proprietary builds.
Can I script the same logic locally?
Yes. fflate in Node reproduces the detection exactly; the cookbook above has a working snippet. Validity still needs apksigner/jarsigner.
Which formats can it read for a dev artifact?
ZIP, JAR, APK, AAR, GZIP, TAR natively, plus 7z/rar/bz2/xz via libarchive WASM. The APK-block check needs a ZIP-structured container.
Does it support reproducible builds directly?
It does not produce builds, so no. For reproducible archive output use Timestamp Normalizer and bind results with Checksum Generator.
Privacy first
Every JAD Archive tool runs entirely in your browser using fflate, @zip.js/zip.js, and the libarchive WASM bridge. Your archives never leave your device — verified by zero outbound network requests during processing.