Handle missing VDU better in In QuickJS scanner plugin
Previously we tried to run the VDU query prompt even if there was not VDU. That
would have yielded a match anyway as both result in an error, but it added
noise to the logs.
Handle the missing VDU like we handle the missing filters in
filter_doc_validate.
f9e0eed...
by
Robert Newson <email address hidden>
Merge pull request #5057 from apache/jwt-exp-by-default
JWT: require valid `exp` claim by default
3aa3f1d...
by
Robert Newson <email address hidden>
JWT: require valid `exp` claim by default
Users of JWT rightly expect tokens to be considered invalid once they expire. It
is a surprise to some that this requires a change to the default
configuration. In the interest of security we will now require a valid `exp`
claim in tokens. Administrators can disable the check by changing
`required_claims` back to the empty string.
We do not add `nbf` as a required claim as it seems to not be set often in
practice.
Some dependencies were held back due to older CentOS and Ubuntu, now we can
update them.
Try to replace CentOS7 with CentOS9 in the full CI and use the "no spidermonkey
whatsoever" CI variant as well.
f82be73...
by
Nick Vatamaniuc <email address hidden>
Add QuickJS as a Javascript engine option
Some benefits over Mozilla Spidermonkey:
* Small. We're using 6 or so C files vs 700+ SM91 C++ files.
* Built with Apache CouchDB as opposed having to maintain a separate SM
package, like for RHEL9, for instance, where they dropped support for SM
already [1].
* Embedding friendly. Designed from ground-up for embedding. SM has been
updating the C++ API such that we have to keep copy-pasting new versions of
our C++ code every year or so [2].
* Easy to modify to accept Spidermonkey 1.8.5 top level functions for
map/reduce code so we don't have have to parse the JS, AST transform it, and
then re-compile it.
* Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so
we can afford to do that on reset. JSRuntimes cannot share JS data or object
between them.
* Seems to be faster in preliminary benchmarking with small
concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758
Results seem promising:
- 4x faster than SM 1.8.5
- 5x faster than SM 91
- 6x reduced memory usage per couchjs process (5MB vs 30MB)
* Allows compiling JS bytecode ahead of time a C array of bytes.
QuickJS can be built alongside Spidermonkey and toggled on/off at runtime:
```
./configure --dev --js-engine=quickjs
```
This makes it the default engine. But Spidermonkey can still be set in the
config option.
To test individual views, without switching the default use the
`javascript_quickjs` language in the design docs. To keep using Spidermonkey
engine after switching the default, can use `javascript_spidermonkey` language
in design docs. However, language selection will reset the view and the view
will have to be rebuilt.
It's also possible to build without Spidermonkey support completely by using:
```
./configure --disable-spidermonkey
```
