RFC: Add Audit Policies Support

[darcyclarke]

Rendered RFC

[ljharb]

the query specifies which packages are selected, but what defines how the results are presented?

Vulnerability output is perhaps a special case, but is the output just "error, nonzero packages showed up in the query!"?

[darcyclarke]

Great question - I believe the idea would be to use something like the above but I can put some potential examples of output in the RFC itself

[ljharb]

I think that it won't be nearly as useful if all i can do is control the exit code with a query that produces nonzero results. I suspect people will want to provide their own package that can be a function that receives the query results as an argument, and can do whatever it likes, as long as it returns an exit code, or something.

[naugtur]

Hello!

Where does the JSON go? If it's in a policies file, it feels like I could use it for npm-audit-resolver to specify what to ignore too.
Can we consider an ignore condition here? Or setting the policy to error on all vulnerable and then specify exceptions with queries for each?

Do at me ;)

[darcyclarke]

@naugtur the original idea was to have these policies live in package.json & get picked up by npm audit (they would then also apply during install or update if --audit=true); I can/should expand the RFC to note this & other specifics left out today (including what inclusion/exclusion might look like - although I think it would be fairly straightforward ie.
DSS combinators ex. :vulnerable:not(.dev, ...), but maybe you're hoping for more flexibility in composition of which policies to run[?])

[ljharb]

I think putting them in package.json, thereby inflating the size of the packument and published packages, is probably not the best idea - a separate JSON file seems ideal.

[naugtur]

Yeah, I remember we iterated through all the options of "where to put audit specific information of which we'll need plenty" in the audit-resolver RFC reaching the conclusion that there's no existing file that would accommodate if well.
I'm not sure if I'll make it to the meeting today at all, but happy to help out with this whenever I can.

Also, if these are running before a package is installed to help make a decision, I have a bunch of use-cases for them and there's very little requirements to put in this RFC that'd enable those use-cases. At least it seems so from my initial reading of the PR here.

[bnb]

I think putting them in package.json, thereby inflating the size of the packument and published packages, is probably not the best idea - a separate JSON file seems ideal.

IMO adding more files is not good. We already have too many files, adding more will only decrease visibility / add the burden of additional knowledge.

[ljharb]

@bnb "too many files" is a subjective opinion - separate files allow you to have granular CODEOWNERS, as well, beyond being data that doesn't belong in a published package. The burden exists regardless because you still have to google for how to configure the package.json field.

[bnb]

noting a combination of suggestions from the office hours: if there were a top-level package.json property like npmConfig, having the ability to have audit policies and the ability to point to a file (or a module!) rather than having a pre-determined filename, both options could be supported. If policies as a devDep is an option, there's also so much flexibility for both large-scale open source projects and companies alike.

[ljharb]

i'd be totally fine with a field that optionally points to a file so that the config is discoverable AND the contents don't have to live in package.json :-)

[rondales]

Rendered RFC

[rondales]

Rendered RFC

[rondales]

accepted/0000-npm-audit-policies.md

[rondales]

accepted/0000-npm-audit-policies.md