Audit log design

July 31, 2019, conference call


Issue: -- putting summary of this meeting in a comment on that issue

Goal: review approaches to designing audit log functionality

Basic design approach for auditing API

Will asked a few general approach questions.

How do we want the auditing API to look? 3 choices:

Our choice: New API, called in tandem with metrics calls in places where both are needed/desired.


2nd question: Storage! How long a duration? Up to last n auditable records, up to last n weeks, FOREVERRR, etc.? maybe not do this inside of Postgres, use a document store?

Our journal is just Postgres tables. 2 classes of audit info to store:

Will: what about API tokens? question of security boundary. Maintainer seeing whether an Owner has created an API token

General discussion:

Scope of this task

Will: scoping questions: Trail of Bits is scoped to work on (as mentioned in ):

Some of this is fuzzy.

Ernest: implementing necessary API calls internally is most important for scope, then implementing a handful of auditable events, creating admin view for it, exposing what makes sense TODAY. And storage. Simplest case:

Project aspect: enhancing current view when logging into project history

Right now: ensure we can store and retrieve. We can add more auditable events down the line.

Donald: ideally only a few lines of code to add a new event type

Will: yes - event tag, and optional things (user, project) - human-readable description, assoc metadata

Nicole: re duration of storage:

Will: store project-related events indefinitely.

User events: a limit.

Will: garbage collection, recycle in databases.... how does he make sure events get properly flushed?


Sumana: Email notifications like are out of scope




Re: who gets to see what?

Estimated date of completion for audit logging functionality

Will: estimate: can have additional models and views done by probably end of next week. Then, work with Nicole on UI and - for initial merge - determining initial events to expose

Nicole: then another week or so to have templates merged.

Resolved: Try to work towards merging on Aug 16

(But let's not be surprised if getting out of beta on WebAuthn and API keys ends up slowing this down)


Ernest: **Important** INVOICES 4 JULY PLZZZZZZZ <3 **Important**: We need to update our view on runway :)


  1. Will, Nicole, and Sumana: submit July invoices ASAP
  2. Nicole: look into best practices/prior art for how long to store user behavior in this audit log --

PackagingWG/2019-07-31-Warehouse (last edited 2019-08-01 02:13:56 by SumanaHarihareswara)

Unable to view page? See the FrontPage for instructions.