Add Embedded Lua for Flexible Filters, Asserts and Captures

[ossie-git]

Problem to solve

I was wondering if there is any direction of embedding something like Lua (or JavaScript) to allow for custom filters, asserts and captures. For example, I ran into an issue where the server may return more than one HTTP response code and I would be OK with either one (such as the issue mentioned here: #2035).

I understand that hurl tries to be easy to use and dislikes flexibility, but a feature like this would allow advanced users to add custom filters, asserts and captures.

Proposal

I don't know Rust but I have seen praise for the mlua crate.

Additional context and resources

Tasks to complete

• ...

[jcamiel]

Hi @ossie-git

Thanks for the issue. It's really unlikely that we add such a feature, we're trying very hard not to add dependencies, even if it means having a less flexible tool. On the security side of thing, I'm really not at ease with embedding script capabilities inside a Hurl file, that could, for instance, erase some random directories.

That said, in a (near) future, Hurl will have a better support for expression, something like:

GET https://foo.com
HTTP 200
[Asserts]
status == 200 or status == 201

[ossie-git]

Hi @jcamiel

mlua uses a sandboxed embedded Lua implementation that removes dangerous packages including:

• io. library has been removed entirely, as it gives access to files and allows running processes

• package. library has been removed entirely, as it gives access to files and allows loading native modules

• os. library has been cleaned up from file and environment access functions (execute, exit, etc.). The only supported functions in the library are clock, date, difftime and time.

• debug. library has been removed to a large extent, as it has functions that aren’t memory safe and other functions break isolation; the only supported functions are traceback and info (which is similar to debug.getinfo but has a slightly different interface).

• dofile and loadfile allowed access to file system and have been removed.

So they have removed all the potentially dangerous functions in Lua. As an additional layer or protection, this feature can be added behind a compile time feature flag so that users who wanted it would have to compile it, enabling the feature flag

[jcamiel]

Hi @ossie-git, thanks for your comment,

• what's a guarantee that some module are not going to be enable?
• how many dependencies come from this crate? Is is a pure Rust crate or does it needs a native binding? If it needs a native bindings, what needs to be additionally installed on the system?
• what's the maturity of the crate? Is is stable enough? Is it a 1.x release so at least some API stability is expected?

I'm sorry I will be hard to convince 😅: the fewer dependencies we have, the simpler the maintainer job is!

[ossie-git]

Hi @jcamiel

I doubt I'll win this discussion but here goes:

• the project (mlua) is pretty mature and actively maintained (it has been around since 2019). However, it still hasn't hit 1.0
• it supports embedding a number of Lua implementations (5.1, 5.2, 5.3 and 5.4, luau, etc.). You specify this in your Cargo.toml file. Some of these require that you have Lua installed while others don't (luau doesn't from my understanding and therefore it has fewer dependencies). The most interesting of these is luau which is a version that has removed the libraries I mentioned above. It is also the version used and developed by the massive gaming platform Roblox, which has been using a sandboxed version of Lua 5.1 to allow game developers to develop their games in Lua and deploy them on the platform since 2006. It hosts millions of user-created games, so it is battle-tested in production including its sandboxing. They took Lua 5.1, sandboxed it, improved it, and added some additional features such as type annotations and type inference
• it is used by several other popular projects including:
  • vector
  • yazi
  • xplr
  • ox
  • qsv
  • HexPatch

[lu-zero]

https://github.com/rhaiscript/rhai would be a better fit since you can easily reduce the language and it is pure rust.

[ossie-git]

@lu-zero While it appears more Rust-native, from what I understand, it:

• is relatively slow (https://github.com/khvzak/script-bench-rs)
• does not support some useful features such as regex (I'm not 100% sure but I tried to find more details on regex support and couldn't find anything)
• I think more people know Lua than a custom Javascript-inspired language

[fabricereix]

While adding an external interpreter seems very attractive in terms of flexibility,
I think it will conflict with some of the Hurl core values:

• small binary size and memory footprint (designed for CI/CD)
• security
• declarative/simple textual language

As mentioned before, we plan to add expression to the language, which should make it a lot more flexible.
It's always interesting to hear about new use cases that Hurl does not really support.