0.6.0

Notable Changes

• Fixed compatibility issue with newer versions of Envoy. #302
• Plugins can be loaded over HTTPS. #309
• Outbound HTTP API is now exposed in the SDK. #342
• The WebAssembly engine has been upgraded to wasmtime 22. #354
• Added smoke test covering the majority of the plugin API. #361

Full Changelog:

• 0.5.0...0.6.0
• https://github.com/bulwark-security/bulwark/milestone/5?closed=1

0.5.0

• Redesigned the plugin API to parameterize request/response/labels/verdict and explicitly return outputs.
• Plugins no longer need to declare an explicit dependency on wit-bindgen, undoing the change in 0.4.0.
• The WebAssembly engine has been upgraded to wasmtime 19.
• Added integration tests covering Redis and Envoy.
• Improvements to the organization of the config file format.

Full Changelog: 0.4.0...0.5.0

0.4.0

• The WebAssembly engine has been upgraded to wasmtime 15.
• The build subcommand has been updated to create the necessary WIT files for plugins.
• Plugins now need to declare an explicit dependency on wit-bindgen.
• Degree-of-conflict is now measured between plugin decisions.
• Maximum concurrency is now configurable.

0.3.0

The WebAssembly engine has been upgraded to wasmtime 11. A new build subcommand has been added the the CLI to simplify the build process for plugins. New on_request_body_decision and on_response_body_decision handlers have been added to allow plugins to process HTTP bodies.

0.2.0

The WebAssembly engine has been upgraded to wasmtime 10. Bulwark switched to using the WASI component model in the process. This resulted in some changes to how plugins declare their handlers. The SDK now includes a bulwark_plugin procedural macro which is invoked like this:

use bulwark_wasm_sdk::*;

pub struct ExamplePlugin;

#[bulwark_plugin]
impl Handlers for ExamplePlugin {
    fn on_request_decision() -> Result {
        let _request = get_request();
        set_decision(Decision {
            accept: 0.0,
            restrict: 0.0,
            unknown: 1.0,
        })?;
        set_tags(["example-plugin"]);
        Ok(())
    }
}

After a plugin is compiled, it will need to be transformed into a component. This is inconvenient and a future release will likely not require this step, but for the time being it's required in the interests of expediency. The reactor shim needed can be downloaded from the wasmtime dev tag. The wasm-tools binary can be installed with cargo install wasm-tools.

wasm-tools component new target/wasm32-wasi/release/example_plugin.wasm --adapt wasi_snapshot_preview1=wasi_snapshot_preview1.reactor.wasm --output dist/example_plugin.wasm

The resulting .wasm file may then be run by Bulwark as a plugin.

Additionally, there have been some API changes to error handling. Plugins may now recover from errors that previously would have been a panic in 0.1.0. A new API call, append_tags was also added to allow plugin code to add tags bit-by-bit instead of all-at-once.

Initial release

Merge pull request #1 from bulwark-security/rc1

Initial release version