Appendix B Audit Events

2 min read

Every event described here is emitted into the kernel event subsystem (§13.3). The caller's identity is stamped into the event header by the kernel and is not part of the payload.

These types also appear in the Peios Events Index, alongside every other event the system emits.

B.1 Types #

TypeEmitted forEmitted today
peipkg.installA successful installyes
peipkg.upgradeA successful upgrade, downgrade, or undoyes
peipkg.uninstallA successful uninstallyes
peipkg.refreshA repository refresh, successful or partially failedyes
peipkg.transaction-failedA rejected or rolled-back transactionyes
peipkg.recoveryA recovery resolved through peipkg recoveryes
peipkg.authorisationAn operator authorisation recordyes
peipkg.repo-addA repository addyes
peipkg.repo-removeA repository removeyes
peipkg.claimA claim grant or revokeyes
peipkg.config-changeA trust-policy or transport-flag changeno

B.2 Payload fields #

FieldContent
txn_idThe transaction identifier
outcomesuccess, rejection, or rollback
repoThe repository, for repository operations
detailThe rejection reason, the operation count, or the authorised action
timestampRFC 3339, UTC
packagesName, version, and architecture per package

B.3 Where events do not appear #

  • An install or upgrade event carries no source repository, although one is known.
  • A committed cross-root operation's success event carries no transaction identifier.
  • Automatic recovery at the head of an ordinary operation emits nothing.
  • peipkg recover's failure paths emit nothing.
  • Declining at a prompt emits nothing.
  • Enabling insecure transport, and installing unsigned content under an optional policy, emit no authorisation record.
  • peipkg-compose emits nothing at all.

B.4 What emission depends on #

An audit privilege on the caller's token. Without it, emission fails, peipkg warns, and the operation proceeds unaudited.

On a kernel with no emit call, emission is a silent successful no-op.

Edit this page