I tried to compile Envoy with libmodsecurity, but it requires some dynamic libs like xml2, pcre and so on, as a result, to compile or run Envoy, these dynamic libs must be installed in the environment. Is it also nesscessary in Gloo Envoy? PLease help, thanks!

The following is a curated enumeration of the functional changes to the Inja library as we consume it when upgrading from v2.1 to v3.4. This is to track the work required to support solo-io/gloo#8177

2.2

• ✔️ [CHANGE] Environment() constructor changed to use empty string instead of "./". link
  • ensure we aren't calling naked Environment() anywhere
  • this change was reverted in 3.4
• [FEATURE] added at function to access elements in an array by index link
  • index out of range?
• ✔️ [CHANGE] Environment's load_json will throw exception if file not found link
  • trace codepaths that use this and ensure we aren't using any
• [FEATURE] add whitespace control options trim_blocks and lstrip_block link jinja reference
• [FEATURE] a template can be included inside a loop, retaining the parent context link
• ✔️ [CHANGE] Environment's Impl class removed link
  • ensure we aren't using this piece of Environment

3.0

• ✔️ [CHANGE] Reworked exception throwing link
  • ensure we're not relying on the format of exceptions thrown out of inja; update accordingly
• [FEATURE] Loop features index, index1, is_first, is_last can be used when looping over objects (maps) link
• [PERFORMANCE] Improved performance when looping over large datasets link
• ✔️ [CHANGE] removal of polyfill; not sure what was being polyfilled link
  • ensure we build without this
• [FEATURE] disable searching for templates on file system link
  • New field in ParserConfig
  • Expose or explicitly enable depending on how we currently allow template configuration
• [FEATURE] disable throwing an exception if included template not found link
  • New struct RenderConfig
  • Expose?
  • Test envoy behavior with/without setting with missing include
• [FEATURE] add fine-grained whitespace control for statements e.g. {%+, {%-, -%} link
• ✔️ [CHANGE] Node constructor signatures all changed to require size_t argument link
  • ensure we are not calling this constructor anywhere
• ✔️ [CHANGE] Major rewrite of core (AKA the big one) link
  • Parser constructor now take 4 args instead of 3
    • 4th argument function_storage...
  • Pointer element notation removed from Parser config JSON Pointer RFC
    • test Envoy behavior if templates use pointer notation
    • explore possibly translating JSON pointers as a stopgap
• [FEATURE] Plus, minus, times, slash, percent, power tokens added
  • test these operations for common errors, validate envoy behavior if failure
    • e.g. divide by zero, operations on NaN tokens
• ✔️ [CHANGE] Numerous methods in Parser and Renderer made private link
  • ensure we build with this
• [FEATURE] exists operation extended to be able to safely chain json pointers link
  • e.g. exists("array.1.name") can be used instead of the multiple calls exists("array"), existsIn("1", array), and existsIn("name", array.1)
• [FEATURE] AtId operation added to access specific elements in a list of objects link
• [PERFORMANCE] strings are no longer copied around needlessly link

3.1

• [FEATURE] Add set statement to mutate data link
  • verify this only affects current scope and all child scopes; not parent scope
• ✔️ [CHANGE] numerous values changed to const link
  • verify we build with this
• [FEATURE] Add void callback link
  • we could use for logging or mutating dynamic metadata or modifying stats
• [FEATURE] add fine-grained whitespace control for expressions e.g. {{%-, -%}} link
• [FEATURE] consume UTF-8 byte order mark (BOM) link
  • this will not affect us

3.2

• [FEATURE] Allow variables starting with @ and $ link
• [FEATURE] Inja can be configured to abort instead of throw link

3.3

• [CHANGE] short-circuit evaluation link
  • We need to add documentation around this. test case link
• [FEATURE] inheritance between templates link
  • we should add extensive testing around this in case users build mega-templates with multiple levels of inheritence
• [FEATURE] set statements can access child data via dot notation (not pointer notation as the docs state) link
• [FEATURE] add fine-grained whitespace control for comments e.g. {#-, -#} link
• [FEATURE] at can be nested to dynamically access object fields link
  • see test case for usage
• [FEATURE] join function added to join lists with a separator link

3.4

• [FEATURE] include callback link
  • this should be of limited use to us since we do not include from filesystem
• ✔️ [CHANGE] Environment fields input_path and output_path changed from Public to Protected link
  • ensure we build with this
• ✔️ [CHANGE] Environment() constructor changed to use "./" instead of empty string link
  • this is a reversion of a change in 2.2, no action should be required
• [CHANGE] passing too few arguments to a function throws a parser error link
  • test envoy behavior when this error is thrown

Enable all our devs that want to build envoy to use the remote bazel build cache to speed up envoy dev.

Gloo JWT plugin is unable to handle JWTs generated by Keycloak.

Possibly related to:
envoyproxy/envoy#10222
google/jwt_verify_lib#43

add:

• be able to extract regex from body
• be able to ref the body from inja template
• be able to add templates to dynamic metadata

We should explicitly declare **enrivon to make it clear on Mac (and others) that it's declared in scope

Upstream has had some amazing work done on its ci in 1.26

This put us in an unenviable space where we had to change our envoy-gloo release process from relying on the upstream do_ci.

Our current work around is to checkout 1.25 to use that ci script as our base.

In this issue we MUST decide if we are to move off from upstream do_ci or to update our ci to work with the new upstream ci scripts.

This MAY include putting up prs for envoy that may only be in 1.27+ but we shouldnt rely on this checkout strategy for the long time.

Currently there are 2 body transformation types available in the transformation filter:

1. full body transformation
2. Merge extractors to body

It would be very useful to be able render templates to modify or add specific keys within the existing JSON body.

JWTs and other usages use a modified character set from the standard base64. This variant is called base64url. When our Transformation filter is presented with a base64url encoded string to the base64_decode inja callback, the transformation fails silently because the decode returned an empty string.

We need to update to the latest version of envoy-wasm to pull in envoyproxy/envoy-wasm#623 which fixes a major bug for which we have several temporary workarounds in our code.

While trying to build the project to ARM the command make fast-build-arm fails with:

ERROR: Skipping '//contrib/...': no targets found beneath 'contrib'
ERROR: no targets found beneath 'contrib'
INFO: Elapsed time: 3.005s
INFO: 0 processes.
ERROR: Couldn't start the build. Unable to run tests

Can you help?

As described in the Gloo issue solo-io/gloo#6956, a segmentation fault occurs when a SNI is configured on an Upstream SSLConfig.

After some analysis (see comments + reproducer in solo-io/gloo#6956), I figured out that the problem occurs within the Envoy pre-release version 1.23.0 (https://github.com/solo-io/envoy-gloo/blob/v1.23.0-patch3/bazel/repository_locations.bzl#L4).

As shown in the reproducer, the problem does not occur in the final Envoy release 1.23.0.

Univision is looking to remove some json keys from the body if certain properties.

Here is the javascript code they currently use to remove it

var content = context.getVariable("request.content")
if ( content !== '' ) { 
    if ( JSON.parse(content).hasOwnProperty('video') ) {
        var payload = JSON.parse(content)
        video = payload['video']; 
        if ( video.hasOwnProperty('mediaId') ) {
            var mediaid = payload['video']['mediaId']+"";
            if ( mediaid.match(/^transmission:matchid:.*/) ) {
                payload['video']['mediaId'] = "video:mcp:unexpected-live-match";
                context.setVariable('request.content', JSON.stringify(payload));
            }
        }
        if ( video.hasOwnProperty('seriesMediaId') ) {
            var seriesmediaid = payload['video']['seriesMediaId'];
            if ( seriesmediaid === "" ) { 
                delete payload['video']['seriesMediaId'];
                if ( video.hasOwnProperty('nextEpisodeMediaId') ) {
                    delete payload['video']['nextEpisodeMediaId'];
                }   
                context.setVariable('request.content', JSON.stringify(payload))
            }
        } else if ( video.hasOwnProperty('nextEpisodeMediaId') ) {
            delete payload['video']['nextEpisodeMediaId'];
            context.setVariable('request.content', JSON.stringify(payload))
        } 
    } else {
        context.setVariable('vixdebug.remove_empty_series_media_id','payload does not have a json video object')
    }
}

PR: #347

Envoy version v1.11.2 addresses two CVES. More details in the following issues.

envoyproxy/envoy#8519
envoyproxy/envoy#8520

bump envoy version to address the CVES

Recent envoy commit made the header matching protos public, which allows for use of their header matching code. These matchers are required for the transformation filter going forward.

Now that upstream has also implemented their own lambda filter there are some really nice improvements that we can emulate.

Ideally we would align closer to upstream and slot our authentication and transformation improvements.

TODO: @nfuden link the changes such as:

• splitting out signing to not be lambda specific
• allow lambdas signing to happen later as an http extension so that transforms dont mess up signing

When wrapAsApiGateway and unwrapAsApiGateway were implemented, they were implemented as custom transformers which were defined in envoy-gloo-ee to protect them as enterprise features. After moving unwrapAsApiGateway into OSS, and looking ahead toward other potential request/response transformer implementations, it makes sense to extract the logic for unwrapAsAlb out into a custom transformer as well. This will be more uniform and will serve to simplify the internal API

envoy-gloo/ci/run_envoy_docker.sh file has a line of code which should be commented perhaps? Running the make build-arm or whenever this shell script is invoked give an error.

./ci/run_envoy_docker.sh: line 27: Since: command not found

Current stable enovy release is 1.9.0
but gloo is using 1.10.0-dev