feat(core): add a schema for policy files

[boneskull]

Thought this might come in handy. Needs titles, descriptions and such.

This seems like a reasonable idea for schema versioning.

To test in VS Code, you can add this property to any policy file:

"$schema": "https://raw.githubusercontent.com/boneskull/LavaMoat/boneskull/policy-schema/packages/core/schema/lavamoat-policy.v0-0-1.schema.json"

[boneskull]

Current dependencies on/for this PR:

• main
  • PR chore: replace yarn with npm #629
    • PR fix(lavamoat): allow prefixed builtins #653
    • PR chore: normalize test config #643
      • PR feat(core): add a schema for policy files #620 👈
    • PR chore: add commit hooks #632
    • PR chore: reconfigure lerna for releases #631
    • PR chore(ci): add a release-please configuration #630
    • PR chore: consolidate eslint config #627
      • PR chore(deps): remove @metamask/eslint-config-nodejs #639
      • PR feat(allow-scripts): generate & ship typescript declarations #617

This comment was auto-generated by Graphite.

[boneskull]

@naugtur I'm unsure if we're going to be adopting Endo's policy format, or if they will adopt ours, or what. Here's this, anyway. Please let me know what you think.

[naugtur]

@naugtur I'm unsure if we're going to be adopting Endo's policy format, or if they will adopt ours, or what. Here's this, anyway. Please let me know what you think.

I wrote policy support in Endo to be a low level representation of something powerful enough to support our current format (via translation and setup) but also many other formats.

One of the first steps on the path to rebuilding lavamoat-node on top of Endo is going to be a translation function and an attenuator to consume our current policy shape.

There's also a potential future where our policy allows specifying "network access" as a category that gets translated into what's needed.

[boneskull]

@naugtur Seems like it'd be good then to formalize the policy format.

What I don't have here are things like titles and descriptions of the various properties, and that would be helpful for someone (you?) to provide so that I can fill it in:

• Title/description of entire schema. Currently this is "LavaMoat Policy Schema"
• Title/description of resources prop
• Title/description of globals, builtins and packages within the resources prop
• Title/description of resolutions property (WIP)
• Title/description of moduleRecord property (WIP) and its properties This looks like it's part of some debugging information??

[boneskull]

Converting back to draft. Need to implement moduleRecord and resolutions, as well as probably add some sort of validator for testing purposes. We can choose to validate at runtime later.

[naugtur]

We will not normalize policy between Endo and LAvamoat as their scope differs. Endo's policy is low level, while LavaMoat is aiming to be more human readable. We're hoping to one day have the ability to put more general terms in the policy that'd get translated over to the low level policy like "network":true for better developer experience.

So there's going to be one policy format in Endo and potentially more than one format in LavaMoat

[boneskull]

This looks OK for now.

Usually I'd want to use something like json-schema-to-typescript to generate the .d.ts, but it doesn't support patternProperties or anyOf very well, so I just handrolled it.

[boneskull]

Closing this and opening from new branch