[PATCH audit RFC] audit: add core audit module, extension using it, and a minimal test

[Gregory Szorc]

On Wed, Dec 2, 2015 at 9:38 AM, Mike Edgar <adgar at google.com> wrote:

> # HG changeset patch
> # User Mike Edgar <adgar at google.com>
> # Date 1448701927 18000
> #      Sat Nov 28 04:12:07 2015 -0500
> # Node ID 2a3144c7158e2f80a9ea7ce7da026c1492ffa9e6
> # Parent  389b9907470c61bc502a4e78724aa9b336d81cf6
> audit: add core audit module, extension using it, and a minimal test
>
> This is the first piece of implementing audit trails/chain-of-custody
> tracking
> in core Mercurial, providing minimal core functionality and and an
> extension
> for accessing that core functionality.
>
> For more details on the audit trail design, see:
>
> https://www.mercurial-scm.org/wiki/AuditTrailPlan
>

\o/

I know I'm probably sounding like a broken record, but I *really* don't
like "signature" for recording events in the audit trail because to me it
implies trust and/or verification. I much prefer something generic like
"statement" (e.g. "stmt1"). We can use "signature" to convey the bits that
actually represent trust/verification/crypto/signing.

We should have a bikeshed about namespaces. While I like mpm's suggestion
to "x-" prefix 3rd party items (like HTTP headers), this is often
overlooked in the wild. So if unprefixed is reserved for hg, I think we run
a higher risk of collision. I think the explicit prefixing of hg-reserved
attributes is justified.

By representing commits as merely the SHA-1, this makes verification
difficult if the original changeset isn't available. For things like
cryptographic verification of code review / sign-off where the submitted
changeset is rebased before final push/integration, we talked about a
mechanism to specify what's verified. e.g. you could sign the manifest
SHA-1 or the SHA-1s of only the files that changed. This is sort of
described at https://www.mercurial-scm.org/wiki/CommitSigningPlan. What are
your thoughts on this area? (I'll add proposals to AuditTrailPlan if you
want.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151203/2eaed63d/attachment.html>