42escrow
ProductHow it worksSecurityPricingGet in touch
ENDE

Security

The parts of an escrow service that should not require trust.

An escrow agent asks you to trust it with the thing you least want leaked. So the design goal is to need as little of that trust as possible: deposits you can verify without us, storage that never overwrites, and an audit trail we cannot edit either.

Anatomy of a deposit6 layers
STORAGEIMMUTABILITYVERSIONINGENCRYPTIONRETENTIONCUSTOMER ACCESS
enforced by the systemhonored by process
  1. 01
    Customer accessenforced by system

    None, ever

    No customer holds a storage credential. The only path out is an approved release: a link that expires after 24 hours, points at 42escrow — never at storage — and every download is recorded.

What you can check yourself

The strongest guarantee is the one you do not have to ask us about.

Two checks, both without us: the deposit against your own clone, and the record against its own hash chain.

A deposit, as your auditor sees it

sealed
repository
helios-core
version
412 · 02:02:11 UTC
commit
a3f91c2
sha-256
9f2b41c7…b17d4e92
retention
7 years · until 2033-10-19
storage
versioned by content hash

Recompute that hash from your own clone. If it matches, the archive we hold is the code you were promised.

Verify a deposit

Every deposit shows its commit and the SHA-256 of the stored archive. Reproduce it from your own clone:

$ git bundle create archive.bundle --all$ sha256sum archive.bundle9f2b41c7…b17d4e92  archive.bundle

If it does not match, you have found a problem worth a phone call — before you needed the code, which is the entire point.

Verify the record

Every deposit, download, approval and release is written to an append-only log. Each entry hashes the one before it.

#2111
c41e…
#2112
7a0d…
#2113
e93b…
  • The database rejects UPDATE, DELETE and TRUNCATE on the log — by trigger.
  • Altering any past entry breaks every hash after it.
  • Recomputing the chain is a customer action, not a support request.
  • Customers see only their own organization's entries.

Separation between parties

A depositor and a beneficiary share one agreement and almost nothing else.

Can seeVendorLicensee42escrow
The agreement and its terms
Which repositories are covered
Deposit history, checksums, retention
The repository access credential
The deposited source code
Another organization's records

These are enforced as database row-level security policies rather than as checks in application code, so a bug in a screen cannot widen them.

Honest limits

Things a security page usually leaves out.

Most providers would leave these out. We put them in writing, because blind trust is exactly what escrow is supposed to remove.

42escrow · Security
01

We can read your code

An escrow agent necessarily holds a decryptable copy — otherwise it could not release one. What we constrain is process: no customer path to storage, two-officer approval, and an audit entry for every access.

02

Escrow is not a backup

Deposits are for contractual release, not for your own disaster recovery. If you need a restore path for your own operations, keep one.

03

A deposit proves bytes, not quality

We prove the archive matches the commit. We do not certify that it builds, that it is complete, or that it is the right branch — build verification is a separate service, and we will tell you so.

42escrow · a service by 42law