Grule Rule Engine Versions Save

This release is a security fix for a RCE vulnerability in the go-git dependency.

Details: go-git v4 - CVE-2023049569/CWE-22 - Path Traversal

Overview Affected versions of this package are vulnerable to Path Traversal via malicious server replies. An attacker can create and amend files across the filesystem and potentially achieve remote code execution by sending crafted responses to the client.

Notes This is only exploitable if the client is using ChrootOS, which is the default for certain functions such as PlainClone. Applications using BoundOS or in-memory filesystems are not affected by this issue.

Users loading rules from remote Git servers are encouraged to upgrade to v1.15.0 as soon as possible.

• Fixed wrong package name. changed from grule-rule-engine to `github.com/hyperjumptech/grule-rule-engine'
• Fixed wrong test that previously have not catch the return catch. now it catches the return error properly

After a quite long time, I've finally manage to find some time on recontributing on Grule Rule Engine. Thank you very-very much for all contributors. The following are some collection of changes we did since the last release.

• Been introduce a new linting using golangci-lint, Its there but no yet integrated to the CI yet.
• I tried to remove all code that may yield a panic. change it to response with an error instead of panicking. Unless the function say so, like "MustLoad()", or "MustThis and MustThat". Those function will panic if It sees error. I you guys see a panic. Feel free to tell me or you can give a pull request.

Cheers

• Support for evaluating Interface and Pointer inside the context
• Bump up to use go 1.19

• Increased the Go version to version 1.18. If you still wished to use the version that uses 1.16, please use Grule version v1.11.0.
• FIX #339 Remove the snapshot comparison from every creation of new instance, new test created.
• FIX #334 Functions defined within Interface which added into DataContext can now be invoked from GRL.
• FIX #328 When the engine try to access slice element with out of bound index, it will now emit the error instead of just panicking.

• Git resource bundle loading can now be loaded from a private repo with user and password pair.
• Added an additional string function MatchStringas built in string function.
• Zap logger is now supported in addition to logrus

Note on the Zap Logger :

By default, grule-rule-engine and its subpackages use the logrus logger, which is initialized in the logger subpackage.

The ability to pass a logger (zap or logrus) to subpackages that is initialized in your applications (usually in main.go) has been added.

In each subpackage antlr, ast, builder, engine, the SetLogger (externalLog interface{}) function was added. It can be passed a logger instance (zap or logrus) to be used by the subpackage.

The SetLogLevel() function from the logger package has been changed. Now it is not tied to logrus levels, but uses the levels defined in the logger subpackage of the current library.

• Fixing issue #303 and #304 caused by the AST tree logic bug that misses adding ArrayMapSelector snapshot into the ExpressionAtom.
• Bump up ANTLR4 to use the most recent version

• Adding new built in function MatchString for matching a string to regular expression. fixes issue #281
• A way to track the cause of panic when importing GRB rule binary file. Right now, when the process raises a panic, a panic log were emitted but without showing panic message and the error message were not returned. Now the panic message were displayed in the log and the error returned.

• Minor fix where when using JSON as data into the context, when evaluation is evaluating JSON path beyond the JSON data it self, the evaluation yield a panic. Now evaluating JSON data in context will not panic but instead the rule entry will simply failed the evaluation and rule execution proceed normaly.
• Minor broken link fix in the documentation

• Add option to error on failed grule engine execution
• Fixed #268 : Where everytime engine execute using the same knowledgebase instance, the rule entries are not resetted as intended.