# AERE Verification Layer (sidecar)

A sidecar that runs next to a deployment, on any cloud or on premises, and keeps an **audit log** of it. Every entry is an
AERE Proof Protocol envelope (AIP-23), built by the same `proof-kinds` builder and checked by the same AIP-23 reference
verifier as every other AERE proof, and every entry covers the hash of the one before it (an append-only hash chain,
`hash = sha256(seq | prev | envelope)`, genesis `0x00..00`). The head of the chain can be notarized on Aere Network, which
binds the history up to that head under a post-quantum validator certificate that anyone can check (what such a
certificate proves, and what it does not, is in the AIP-22 erratum of 2026-10-01).

Node.js 24, no dependencies; `notarize-head` alone needs `ethers` (`npm install` in this directory).

## What it proves, and what it does not

- **The content of the entries is what the host says.** The sidecar runs on the host and reads the export the operator makes.
  An entry proves that the host *declared* a container was running, with this image and this configuration, at the time it
  declared (`--at` is also a declaration). It does not prove that the declaration is true.
- **The chain has no key.** Whoever can write the log file can rebuild the whole chain from genesis with any content, and
  `verify-log` on that file alone reports it intact. A partial edit is caught (the chain breaks at the edited entry and
  `verify-log` names it), a full rewrite is not.
- **What is checkable without trusting the host is the history before a published head.** `attest-head` turns the current
  head into an envelope; `notarize-head` records its hash on the AereNotary contract; the AIP-23 reference verifier then shows
  it under a post-quantum certificate (the most recent certified anchor, the parent header bound by hash, its state root, and a Merkle
  proof of `firstSeen[statementHash]`). `verify-log --attested <head.json>` requires that today's log **continues** that head:
  the same first `count` entries, the entry `count - 1` hashing to the attested head. A rewritten or shortened history fails.

- **A head can be signed (2026-09-29).** `keygen` makes an ML-DSA-65 key for the operator; `attest-head --sign-key` signs the
  head statement in the form the AIP-23 reference verifier checks at its `signature` level; `verify-log --attested head.json
  --signer head.pub.pem` then requires that the head was signed by that key. A signature says **who** vouches for the head, not
  **when** (the notarization says when) and not that the history is true: whoever holds the key can sign the head of a rewritten
  history, and without `--signer` a head signed by anyone passes, which the output says.

So: publish heads often (every deployment, or on a timer), sign them with the operator's key, and judge a log against the latest
head you hold from outside the host, with the signer you expect, never on its own.

## Commands

    node sidecar.mjs record --kind runtime --artifact <file> --attested 0x<sha256> [--host h] [--log p] [--at T]
    node sidecar.mjs record --kind deployment --name <name> --version <v> --content-file <file> [--host h] [--log p] [--at T]
    node sidecar.mjs record --kind proof --proof-file <envelope.json>     # any AIP-23 envelope, after checking its form and hash
    node sidecar.mjs scan --source docker|kubernetes --input <export.json> [--host h] [--log p]
    node sidecar.mjs scan --source aws-ecs|aws-ec2|aws-lambda|azure-vm|azure-container|azure-containerapp|azure-webapp|gcp-compute|gcp-run --input <export.json> [--task-definitions <f>]
    node sidecar.mjs verify-log --log p [--attested head.json [--signer head.pub.pem]]   # 0 intact (and continues the head), 1 broken or not continued
    node sidecar.mjs attest-head --log p [--host h] [--out head.json] [--sign-key head.key.pem]   # the head as an aere-audit-head envelope
    node sidecar.mjs keygen --out <dir>                                    # the operator's ML-DSA-65 head key (head.key.pem 0600, head.pub.pem)
    node sidecar.mjs notarize-head --head head.json --rpc <url> --key-file <file> [--notary 0x..] [--out notarized.json]
    node sidecar.mjs bundle --log p [--out bundle.json]                    # {host, count, head, chainOk, entries[]} for a console

The default log is `aere-audit.log` in the current directory. Writers take a lock file beside the log (`<log>.lock`, holding
the writer's process id), so two writers on the same host do not break the chain; a lock left by a process that no longer
exists is removed after 10 seconds. A log that is already broken is never appended to.

`record --kind runtime` records that a file on the host (the binary that runs) has the digest you expected: `matches` says
whether it does. `record --kind deployment` records the digest of a deployed artifact, never its content.

## The runtime adapter

`scan` reads an export the operator makes on the host, so the sidecar needs no access to the Docker daemon, the cluster, or
any cloud credential:

    docker inspect $(docker ps -q) > export.json          # then: scan --source docker --input export.json
    kubectl get pods -A -o json > export.json             # then: scan --source kubernetes --input export.json

For every container that is **running**, it writes a canonical descriptor (image and image id, name, namespace and pod on
Kubernetes, start time, restart count, the **hash** of the command line, the **names** of the environment variables, the
destinations of the mounts) and records the descriptor's digest as a deployment entry. No environment value, no argument in
clear and no host path of a mount is stored. The descriptors themselves are written beside the log
(`<log>.descriptori.jsonl`), so an auditor can re-hash each one and compare it with the chain. An export with no running
container, or one that is not in the expected shape, is refused rather than recorded as "zero deployments".

A hash does not hide a guessable secret: if a password is passed on a command line, anyone who knows the rest of the command
can test guesses against `commandSha256`. Pass secrets through files or the environment, not arguments.

## Cloud exports (2026-10-18)

The same adapter, in the same honest form, for the workloads a cloud runs for you: the operator makes the export **with the vendor's
own CLI and their own credentials, on their own machine**; the sidecar reads the file. The sidecar holds no cloud credential and
calls no cloud API. These adapters are measured on the outputs **as the vendors document them** (`fixturi-cloud/`, every file an exact
copy of a documented example or, for GCP, a form built from the documented schema), **not on a live account**: Aere Network has no
AWS, Azure or GCP account. What a live export carries beyond the documented example is handled as documented and is NOT MEASURED;
a test account at each vendor is what it would take to measure it.

    aws ecs describe-tasks --cluster C --tasks $(aws ecs list-tasks --cluster C --query 'taskArns' --output text) > tasks.json
    aws ecs describe-task-definition --task-definition <family:revision> > def.json      # one per task definition in use
    node sidecar.mjs scan --source aws-ecs --input tasks.json --task-definitions def.json   # def.json may hold one output or a JSON list of them
    aws ec2 describe-instances > ec2.json;                node sidecar.mjs scan --source aws-ec2 --input ec2.json
    aws lambda list-functions > lambda.json;              node sidecar.mjs scan --source aws-lambda --input lambda.json
    az vm list -d > vm.json;                              node sidecar.mjs scan --source azure-vm --input vm.json
    az container show -g G -n N > aci.json  (collect several into a JSON array);  node sidecar.mjs scan --source azure-container --input aci.json
    az containerapp list > aca.json;                      node sidecar.mjs scan --source azure-containerapp --input aca.json
    az webapp list --show-details > web.json;             node sidecar.mjs scan --source azure-webapp --input web.json
    gcloud compute instances list --format=json > gce.json;  node sidecar.mjs scan --source gcp-compute --input gce.json
    gcloud run services list --format=json > run.json;    node sidecar.mjs scan --source gcp-run --input run.json

What each adapter reads, and what it refuses:

- **Only what the export says is running.** ECS: tasks and containers with `lastStatus` `RUNNING`; EC2: `State.Name` `running`;
  Azure VM: `powerState` `VM running` (the field `-d` adds; an export without it is refused, it does not say whether a machine runs);
  Container Instances: `containers[].instanceView.currentState.state` `Running` (`az container list` may omit `instanceView`; such an
  export is refused and `az container show` is asked for); Container Apps: `runningStatus` `Running` (`Progressing`, `Stopped`,
  `Suspended` and `Ready`, which the API enumerates without defining, do not count); App Service: `state` `Running`; Compute
  Engine: `status` `RUNNING`; Cloud Run: the `Ready` condition `True`. Lambda is the exception the vendor documents: `list-functions`
  does not return `State`, so every function listed is recorded as deployed with `state: not-in-export`; when the export carries
  `State` (from `get-function-configuration`), only `Active` functions enter.
- **A file that is not the named CLI's output is refused by name** (`the input is not the output of \`aws ecs describe-tasks\``),
  as is an export with no running workload: a zero is not recorded.
- **Identity.** The image with its digest when the export has one (`imageIdentity: digest`: an ECS `imageDigest`, an image given as
  `name@sha256:...` on Container Instances, Container Apps or Cloud Run); otherwise the id of the machine or service and the image or
  runtime the export declares, marked `imageIdentity: declared` (an AMI id, an Azure `imageReference`, a GCE boot disk and its
  licenses, a `DOCKER|image` or `NODE|20-lts` runtime); Lambda carries `CodeSha256`, the digest of its package (`codeSha256`). An
  entry's name is the region or zone and the workload's own identifiers (`ecs:cluster/task/container`, `ec2:region/instance`,
  `lambda:region/function`, `azvm:group/name`, `aci:group/name/container`, `aca:group/app/container`, `azwebapp:group/site`,
  `gce:zone/name`, `run:region/service/container`), and its version the digest when there is one.
- **Names only, never values.** Environment variables enter as their names (ECS: `environment` and `secrets` of the task definition
  plus `overrides`; Lambda: the keys of `Environment.Variables`; Container Instances: `environmentVariables`, neither `value` nor
  `secureValue`; Container Apps: `env`, with `secretRef` names, never `configuration.secrets`; App Service: `appSettings` and
  `connectionStrings` names; Cloud Run: `env`, never `value` or `valueFrom`). EC2 tags, Azure tags, GCE labels and GCE metadata enter
  as keys (`startup-script`, `user-data`, `ssh-keys` live in metadata, with values the adapter never copies). `customData` and
  `userData` of a VM, the admin user, SSH keys, registry credentials, IP addresses and host names are **not copied at all**; an
  ECS secret's `valueFrom` ARN is not copied either. Where the export does not carry the names (ECS tasks without their task
  definition, a site listed without `--show-details`), the descriptor says so (`envSource: not-in-export`, `siteConfigInExport:
  false`) instead of pretending.

As with Docker and Kubernetes, an entry proves that the export *declared* the workload, at the time the operator says: the vendor's
API answered the operator, and the operator handed the file to the sidecar. Nothing here checks the export against the vendor.

## Notarization

`notarize-head` reads the chain id from the RPC endpoint (it does not trust an argument), refuses an attestation whose
statement does not match its hash before sending anything, and sends nothing if the head is already notarized. On chain 2800
(Aere Network mainnet) the notarization is a real transaction paid by the key's account, so it is sent only with
`AERE_CONFIRM_MAINNET=yes`. The key is read from a file (`d=<hex>` or `PRIVATE_KEY=0x<hex>`) and never printed; error
messages are cut before any long hex string.

`dovezi-notarizare-testnet/` holds a real run on the public testnet (chain 28001): a log of three test deployments and its
head, notarized in block 3,699,939 on 2026-09-27. Anyone can check both halves:

    node sidecar.mjs verify-log --log dovezi-notarizare-testnet/audit.log --attested dovezi-notarizare-testnet/cap-notarizat-28001.json
    node verify-proof.mjs dovezi-notarizare-testnet/cap-notarizat-28001.json      # the AIP-23 reference verifier (aere.network/tools)

The first says the log is the one that was notarized; the second, measured on 2026-09-29, reports `finality: PASSED
post-quantum` under a certified anchor of the testnet, and `VALID`.

## The log as a Merkle tree (RFC 9162)

The same entries, seen as a Merkle tree in the manner of Certificate Transparency 2.0 (RFC 9162, section 2.1): leaf i is the hash
the chain already gives entry i, with the RFC's separation between leaves (`0x00`) and nodes (`0x01`). With the chain alone, checking
that one entry is in the log, or that a new head extends an old one, means receiving and replaying the whole log; with the tree, a
proof of about log2(n) hashes is enough and shows no other entry.

    node sidecar.mjs tree-head --log audit.log --sign-key head.key.pem --out tree-head.json    # size and root, an AIP-23 envelope
    node sidecar.mjs prove-inclusion --log audit.log --seq 7 --out inclusion.json
    node sidecar.mjs verify-inclusion --proof inclusion.json --head tree-head.json --signer head.pub.pem   # no log needed
    node sidecar.mjs prove-consistency --log audit.log --from 12 --out consistency.json
    node sidecar.mjs verify-consistency --proof consistency.json --old head-12.json --new head-20.json --signer head.pub.pem

The tree head is signed with the operator's key in the same form as the chain head (so the AIP-23 verifier checks its signature),
and can be notarized. An inclusion proof carries the entry itself: the verifier recomputes its hash from its content and checks its
envelope, so an internal node cannot be passed off as an entry. A proof names a tree by its size and root; bind it to a head you
received (`--head`), not to the numbers in the proof. Two heads of the same log with no consistency proof between them mean the
history was rewritten. What it does not prove, as for the chain: that the entries are true (the host writes them), or that no
other log with other heads was shown to someone else; whoever receives heads from both, or notarized heads, sees it. A head is
only as good as where you got it: without `--signer`, anyone can make two unsigned heads of an invented log that extend each
other, so both verify commands then say whether each head is signed and by which key, and that no expected signer was checked.

## Tests

    node proba-sidecar.mjs              # 45 checks
    node proba-adaptoare-cloud.mjs      # 60: the nine cloud adapters on the documented exports (fixturi-cloud/)
    node control-negativ-sidecar.mjs    # puts each guard back to its absent form and requires the named check to fail (11 + 27 cloud plantings)
    node proba-arbore.mjs               # 20: the tree (the reference roots of Certificate Transparency for 1..8 leaves, every proof up to 64 leaves, each attack)
    node control-negativ-arbore.mjs     # 14 guards removed in a copy, each turns its named test red

`proba-sidecar.mjs` records runtime, deployment and envelope entries; checks that a modified entry breaks the chain at its
seq, a changed hash is caught, and nothing is appended to a broken chain; that a chain **rebuilt from genesis** passes
`verify-log` alone (the stated limit) but fails against the attested head, as do a shortened log and a modified attestation,
while a log that only grew passes; that a signed head passes the verifier's signature level and `--signer`, while a head
signed by another key, an unsigned head with `--signer`, a damaged signature, and a head signed with a classical key that
declares `ml-dsa-65` are refused; that two writers appending 150 entries each at the same time leave an intact chain of 300;
that a line that is not JSON is reported as broken at its seq; that the Docker and Kubernetes adapters record only running
containers and no secret value; and that every envelope is `VALID` for the AIP-23 reference verifier. The verifier is looked
for at `AERE_VERIFY_PROOF` (`verify-proof.mjs` as published at aere.network/tools, with `verify-anchor.mjs`, `mpt.mjs`, `falcon512.mjs`, `registry-v3.mjs` and `package.json` beside it and `npm install` done there); without
it, the five checks that need it are reported as skipped and the exit code is 2, not 0.

`control-negativ-sidecar.mjs` measured 11 of 11 on 2026-10-05: the version before the review (taken from the development
history, skipped where that history is absent) and ten plantings, each disabling one guard (the requirement that the key of a
head signature be an ML-DSA-65 key, the writer lock, the head
comparison, the length check, the attestation hash check, the handling of an unreadable line, the digest check of `--attested`,
the head signature check, the comparison with `--signer`, the refusal of an unsigned head when `--signer` is given).
`proba-notarizare-testnet.mjs --key-file <testnet key>` repeats the on-chain run above (9 checks, it needs a funded testnet key).

`proba-adaptoare-cloud.mjs` (2026-10-18) runs every cloud adapter on the documented export, on the same export with one stopped
workload added, and on the same export with environment values planted (`fixturi-cloud/`, derived by `deriva.mjs` from the exact
copies in `fixturi-cloud/surse/`, and compared with them at every run): it requires exactly the running workloads with their
identities, no planted value anywhere in the log or the descriptors (and the names present, as the positive control), another CLI's
export refused by name, every descriptor re-hashing to the digest in its envelope, and every envelope `VALID` for the reference
verifier (looked for at `AERE_VERIFY_PROOF` as above; without it that one check is reported as skipped and the exit code is 2, with 59 run). `control-negativ-sidecar.mjs` adds three plantings per adapter (the running filter removed, the names replaced by the
name/value pairs, the shape check removed) and requires each to turn its named check red: measured 38 of 38 on 2026-10-18 in the development tree and 37 of 37 from a fresh clone of the public repository (the case that compares with the pre-review version is skipped there). The
adapters are producers, not verifiers, so they name no rule of the conformance suite (`conformance/`), whose rules are those of the
log and tree verifiers, unchanged.

**Corrected on 2026-10-03.** Until then the check of a head's signature required the DECLARED scheme to be `ml-dsa-65` but not
the key to be an ML-DSA-65 key: a head signed with an Ed25519, RSA or P-256 key that declared `ml-dsa-65` was reported as a head
signed with ML-DSA-65. Found while this verifier was enrolled in the conformance suite (`conformance/`), where it is now a vector.
The key must be an ML-DSA-65 key, or the head is refused by name. Every refusal of `verify-log`, of the inclusion check and of the
consistency check now also carries a rule id from a declared list (`REGULI` in `sidecar.mjs` and `jurnal-arbore.mjs`).

## What it is not (yet)

It does not report to a live console over the network. Its per-cloud adapters (2026-10-18) read the operator's CLI export: no
credentials, no live API calls, and they are measured on the vendors' documented outputs, not on a live account (none is held).
It signs heads, not each entry, and the host name in an entry is still a declaration. No third party has reviewed it.