$ ./verify.sh --deployment
Deployment Verification
Inspect the deployed build identifiers, compare published component hashes, and independently review the open-source cryptographic implementation.
Open Source Policy
PingVaults publishes the cryptographic module, security-critical UI/API snapshots, test vectors, and offline decryptors for review. The rest of the application, build pipeline, scheduler, billing, and deployment remain separate proprietary trust boundaries.
pingvaults-crypto ↗
Encryption core · MIT license · Includes test vectors and offline decryptors
PingVaults (main) — Proprietary
Remaining app · Build/deployment · Billing · Inactivity scheduler
// Why this model: the public crypto layer can be audited independently. The business layer remains proprietary, so verify the deployed controls and network behavior as separate trust boundaries.
Critical Source File Hashes
SHA-256 computed at build timesha256sum <file>on each local source file at build time. For published files, run the command below to compare the corresponding GitHub copy.Verify locally:
curl -sL "https://raw.githubusercontent.com/milshop/pingvaults-crypto/f4355e96783f9764c2c8c3e3180d1613229c47fa/src/crypto.ts" | sha256sumExpected: c9b3f06e77475f75852fb336d541ab7e87bcfda098cdfe0eaaa07f0c511f8d0c
Verify locally:
curl -sL "https://raw.githubusercontent.com/milshop/pingvaults-crypto/f4355e96783f9764c2c8c3e3180d1613229c47fa/components/VaultForm.tsx" | sha256sumExpected: 850a0a8035197af89675c3a07ac5013bf142832e4461e5565e7c3617e493a2e7
A matching hash confirms equality for that published source file only. It does not prove the integrity of the proprietary application, build pipeline, or page reporting the expected value.
One-click Batch Verify Script
Automatically checks all critical files and prints ✓ / ✗
How to run (after copying the script):
macOS pbpaste | bash
Linux xclip -o | bash (or save as verify.sh && bash verify.sh)
The script downloads each published source file from GitHub and compares its SHA-256 with the value displayed by this build. A match confirms file equality, not the integrity of the proprietary application or the page providing the expected hash.
Browser Outbound Request Restrictions (CSP)
Content Security Policy restricts which cross-origin destinations page JavaScript can contact. It is one browser-enforced control, but same-origin APIs remain allowed and must be assessed through source and network inspection.
How to verify: Open DevTools (F12) → Network → click any request → Response Headers → find Content-Security-Policy
Allowed outbound destinations (connect-src):
'self'Same-origin /api/* routes (see details below)/api/vault/saveSave vault (ciphertext + TxID + key schema → database)/api/vault/fetchFetch vault metadata (TxID, salt, iv, key schema)/api/ping/*Query/configure/reset Inactivity Switch settings and check-ins/api/auth/*Email OTP send & verify, Google OAuth, session managementuploader.irys.xyzIrys upload endpoint (older vaults)gateway.irys.xyzIrys read gateway (older vaults)arweave.netArweave fallback gatewayturbo-gateway.comArweave gateway for new uploadsar-io.devArweave fallback gatewayaccounts.google.comGoogle OAuth logincheckout.stripe.comStripe-hosted checkoutapi.stripe.comStripe browser APIHow to verify that 'self' APIs don't send your answers?
CSP only restricts which external domains JS can reach — it can't stop JS from sending sensitive data to its own /api. Use either method below to verify yourself:
1. Open DevTools (F12) → Network tab
2. Go to the vault page, fill in asset clues, click Encrypt & Upload
3. Find /api/vault/save → click it → inspect Payload / Request Body
Expected: ciphertext, salt, IV, recovery schema, and ping settings—without the recovery phrase or derived key
Snapshots of these API routes are published in pingvaults-crypto. Compare their hashes, read the expected behavior, and confirm the live request separately in DevTools:
Cross-origin fetches to destinations outside connect-src are blocked and reported as CSP violations. Requests to listed destinations—including same-origin APIs—remain possible.
JS Bundle Integrity
The main repository is proprietary, so an independent reproducible build is not available. Published source files and live bundle hashes provide useful comparison points, but neither independently proves the complete deployed application.
// L1 (source verification) is the primary method. L2 is an advanced supplement. L3 is unavailable because the main repo is private.
L1 · Source File Hash Verification (Recommended)
Use the batch script to download the published files, recompute SHA-256, and compare them with the values displayed by this build. This confirms equality with those published files.
→ See the batch verify script above
L2 · Live Bundle Hash (Advanced)
Download the compiled JS chunks your browser loads and record their SHA-256. Repeating from different networks or times can reveal inconsistent delivery, but does not identify whether a stable bundle is benign.
→ Find the chunk filename in DevTools → Network, replace HASH in the command below
curl -sL "https://www.pingvaults.com/_next/static/chunks/HASH.js" | openssl dgst -sha256 -binary | base64// These checks provide evidence about published files and observed network boundaries; they are not a complete proof of the proprietary deployment.
Cryptographic Self-Test
Runs an AES-256-GCM encrypt → decrypt round-trip in this page using the shared crypto module. The test does not make a network request.
Test vector:
plaintext "PingVaults crypto OK ✓"
name "Alice"
prompt "Enter the test recovery phrase"
algo PBKDF2-SHA256 × 600,000 → AES-256-GCM
These single-file HTML tools implement the full local decryption flow without loading external scripts. Download them, open them in a compatible modern browser, and inspect the source with View Source.
A saved HTML decryptor, exported metadata JSON, and the separately stored recovery phrase provide a recovery path without a PingVaults account or live service.