profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/PiotrSikora/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Piotr Sikora PiotrSikora @google San Francisco, CA

grpc/grpc-web 5958

gRPC for Web Clients

google/ngx_brotli 1556

NGINX module for Brotli compression

calio/form-input-nginx-module 103

This is a nginx module that reads HTTP POST and PUT request body encoded in "application/x-www-form-urlencoded", and parse the arguments in request body into nginx variables.

agentzh/chunkin-nginx-module 93

HTTP 1.1 chunked-encoding request body support for Nginx

google/ngx_token_binding 39

NGINX module for Token Binding

calio/iconv-nginx-module 32

a character conversion nginx module using libiconv

bazelbuild/rules_perl 12

Perl rules for Bazel

chaoslawful/phoenix-nginx-module 9

Adding regularly restarting, crashing back-trace and other monitoring functionalities to NginX

duderino/everscale 2

A HTTP server, client, and proxy C++ library

PiotrSikora/canicrawl 1

Hosted robots.txt permissions verifier

pull request commentproxy-wasm/proxy-wasm-cpp-host

Add the WasmEdge runtime supporting.

@q82419 this is still failing to build.

q82419

comment created time in 12 days

PullRequestReviewEvent

Pull request review commentenvoyproxy/envoy

stats: introduce CustomStatNamespaces.

 WasmResult Context::defineMetric(uint32_t metric_type, std::string_view name,     return WasmResult::BadArgument;   }   auto type = static_cast<MetricType>(metric_type);+  // Prefix the given name with CustomStatNamespacePrefix so that these user-defined+  // custom metrics can be distinguished from native Envoy metrics.+  const auto prefixed_name = absl::StrCat(CustomStatNamespacePrefix, std::string(name));   // TODO: Consider rethinking the scoping policy as it does not help in this case.-  Stats::StatNameManagedStorage storage(toAbslStringView(name), wasm()->scope_->symbolTable());+  Stats::StatNameManagedStorage storage(prefixed_name, wasm()->scope_->symbolTable());

@jmarantz if you believe that this is a real concern, then please report it using the proper channel (i.e. open a new issue or a PR with the fix), so that it can be discussed there. Side-discussion in the comments of another PR is a recipe for the issue to be lost.

mathetake

comment created time in 12 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentproxy-wasm/proxy-wasm-rust-sdk

WASM module built through Proxy-wasm RUST SDK can't be loaded due to missing imports: due to a missing import: __wbindgen_externref_xform__.__wbindgen_externref_table_grow

You aren't expected to use reqwest (which I suspect is the source of bindgen the issue) to make outgoing calls, this SDK provides dedicated functions to do that (dispatch_http_call, see: examples/http_auth_random.rs).

marklu2018

comment created time in 16 days

issue commentproxy-wasm/proxy-wasm-rust-sdk

dispatch_http_call Cannot load block message

That response comes from the remote server, so you should investigate why it produces it.

Also, you have two definitions for on_http_call_response in your snippet, so I expect it's not representative.

tmtbe

comment created time in 16 days

PullRequestReviewEvent

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Add the WasmEdge runtime supporting.

 def proxy_wasm_cpp_host_repositories():         url = "https://github.com/WAVM/WAVM/archive/93c3ad73e2938f19c8bb26d4f456b39d6bc4ca01.tar.gz",     ) +    http_archive(+        name = "com_github_wasmedge_wasmedge",+        build_file = "@proxy_wasm_cpp_host//bazel/external:wasmedge.BUILD",+        sha256 = "d21fac6e213b438371d6ba12308bbc3bef5842f8a89d9965874a5785c4f970fc",+        strip_prefix = "WasmEdge-0.8.2",+        url = "https://github.com/WasmEdge/WasmEdge/archive/0.8.2.tar.gz",+    )++    native.bind(+        name = "wasmedge",+        actual = "@com_github_wasmedge_wasmedge//:wasmedge_lib",+    )+

Nit: this is inserted between 2 WAVM targets (http_archive and bind), please move it either before or after.

q82419

comment created time in 17 days

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Add the WasmEdge runtime supporting.

+load("@rules_foreign_cc//foreign_cc:defs.bzl", "cmake")++licenses(["notice"])  # Apache 2++package(default_visibility = ["//visibility:public"])++filegroup(+    name = "srcs",+    srcs = glob(["**"]),+)++cmake(+    name = "wasmedge_lib",

It looks that WasmEdge build process tries to fetch and build Boost library if not found, which fails in Bazel.

If it's a required dependency, then I believe that you need to build Boost library in Bazel as well, and then add dependency on it to wasmedge_lib. Perhaps https://github.com/nelhage/rules_boost would work?

If it's not a required dependency, then you need to make sure that CMake won't attempt to fetch it during build process.

q82419

comment created time in 17 days

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Add the WasmEdge runtime supporting.

 std::vector<std::string> getRuntimes() { #endif #if defined(PROXY_WASM_HAS_RUNTIME_WAMR)     "wamr",+#endif+#if defined(PROXY_WASM_HAS_RUNTIME_WASMEDGE)+    "wasmedge",

Nit: sort alphabethically among runtimes.

q82419

comment created time in 17 days

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Add the WasmEdge runtime supporting.

+// Copyright 2016-2019 Envoy Project Authors+// Copyright 2020 Google LLC+//+// Licensed under the Apache License, Version 2.0 (the "License");+// you may not use this file except in compliance with the License.+// You may obtain a copy of the License at+//+//      http://www.apache.org/licenses/LICENSE-2.0+//+// Unless required by applicable law or agreed to in writing, software+// distributed under the License is distributed on an "AS IS" BASIS,+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.+// See the License for the specific language governing permissions and+// limitations under the License.++#include "include/proxy-wasm/wasmedge.h"+#include "include/proxy-wasm/wasm_vm.h"+#include "src/wasmedge/types.h"++#include "wasmedge.h"++#include <array>+#include <cassert>+#include <cstring>+#include <iomanip>+#include <memory>+#include <optional>+#include <sstream>+#include <string>+#include <string_view>+#include <unordered_map>+#include <unordered_set>+#include <utility>+#include <vector>++namespace {++/// Helper templates to make values.+template <typename T> WasmEdge_Value makeVal(T t);+template <> WasmEdge_Value makeVal<proxy_wasm::Word>(proxy_wasm::Word t) {+  return WasmEdge_ValueGenI32(static_cast<int32_t>(t.u64_));+}+template <> WasmEdge_Value makeVal(uint32_t t) {+  return WasmEdge_ValueGenI32(static_cast<int32_t>(t));+}+template <> WasmEdge_Value makeVal(uint64_t t) {+  return WasmEdge_ValueGenI64(static_cast<int64_t>(t));+}+template <> WasmEdge_Value makeVal(double t) { return WasmEdge_ValueGenF64(t); }++/// Helper function to print values.+std::string printValue(const WasmEdge_Value &value) {+  switch (value.Type) {+  case WasmEdge_ValType_I32:+    return std::to_string(WasmEdge_ValueGetI32(value));+  case WasmEdge_ValType_I64:+    return std::to_string(WasmEdge_ValueGetI64(value));+  case WasmEdge_ValType_F32:+    return std::to_string(WasmEdge_ValueGetF32(value));+  case WasmEdge_ValType_F64:+    return std::to_string(WasmEdge_ValueGetF64(value));+  default:+    return "unknown";+  }+}++std::string printValues(const WasmEdge_Value *values, size_t size) {+  if (size == 0) {+    return "";+  }++  std::string s;+  for (size_t i = 0; i < size; i++) {+    if (i) {+      s.append(", ");+    }+    s.append(printValue(values[i]));+  }+  return s;+}++/// Helper function to print valtype.+const char *printValType(WasmEdge_ValType kind) {+  switch (kind) {+  case WasmEdge_ValType_I32:+    return "i32";+  case WasmEdge_ValType_I64:+    return "i64";+  case WasmEdge_ValType_F32:+    return "f32";+  case WasmEdge_ValType_F64:+    return "f64";+  case WasmEdge_ValType_ExternRef:+    return "anyref";+  case WasmEdge_ValType_FuncRef:+    return "funcref";+  default:+    return "unknown";+  }+}++/// Helper function to print valtype array.+std::string printValTypes(const WasmEdge_ValType *types, size_t size) {+  if (size == 0) {+    return "void";+  }+  std::string s;+  s.reserve(size * 8 /* max size + " " */ - 1);+  for (size_t i = 0; i < size; i++) {+    if (i) {+      s.append(" ");+    }+    s.append(printValType(types[i]));+  }+  return s;+}++template <typename T> struct ConvertWordType {+  using type = T; // NOLINT(readability-identifier-naming)+};+template <> struct ConvertWordType<proxy_wasm::Word> {+  using type = uint32_t; // NOLINT(readability-identifier-naming)+};++/// Helper templates to convert arg to valtype.+template <typename T> enum WasmEdge_ValType convArgToValType();+template <>+enum WasmEdge_ValType convArgToValType<proxy_wasm::Word>() {+  return WasmEdge_ValType_I32;+}+template <> enum WasmEdge_ValType convArgToValType<uint32_t>() { return WasmEdge_ValType_I32; }+template <> enum WasmEdge_ValType convArgToValType<int64_t>() { return WasmEdge_ValType_I64; }+template <> enum WasmEdge_ValType convArgToValType<uint64_t>() { return WasmEdge_ValType_I64; }+template <> enum WasmEdge_ValType convArgToValType<double>() { return WasmEdge_ValType_F64; }++/// Helper templates to convert valtype to arg.+template <typename T> T convValTypeToArg(WasmEdge_Value val);+template <> uint32_t convValTypeToArg<uint32_t>(WasmEdge_Value val) {+  return static_cast<uint32_t>(WasmEdge_ValueGetI32(val));+}+template <> proxy_wasm::Word convValTypeToArg<proxy_wasm::Word>(WasmEdge_Value val) {+  return WasmEdge_ValueGetI32(val);+}+template <> int64_t convValTypeToArg<int64_t>(WasmEdge_Value val) {+  return WasmEdge_ValueGetI64(val);+}+template <> uint64_t convValTypeToArg<uint64_t>(WasmEdge_Value val) {+  return static_cast<uint64_t>(WasmEdge_ValueGetI64(val));+}+template <> double convValTypeToArg<double>(WasmEdge_Value val) {+  return WasmEdge_ValueGetF64(val);+}++/// Helper templates to convert valtypes to args tuple.+template <typename T, std::size_t... I>+constexpr T convValTypesToArgsTupleImpl(const WasmEdge_Value *arr, std::index_sequence<I...>) {+  return std::make_tuple(+      convValTypeToArg<typename ConvertWordType<std::tuple_element_t<I, T>>::type>(arr[I])...);+}++template <typename T, typename Is = std::make_index_sequence<std::tuple_size<T>::value>>+constexpr T convValTypesToArgsTuple(const WasmEdge_Value *arr) {+  return convValTypesToArgsTupleImpl<T>(arr, Is());+}++/// Helper templates to convert args tuple to valtypes.+template <typename T, std::size_t... I>+uint32_t convArgsTupleToValTypesImpl(std::vector<enum WasmEdge_ValType> &types,+                                     std::index_sequence<I...>) {+  auto size = std::tuple_size<T>::value;+  if (size > 0) {+    auto ps = std::array<enum WasmEdge_ValType, std::tuple_size<T>::value>{+        convArgToValType<typename std::tuple_element<I, T>::type>()...};+    types.resize(size);+    std::copy_n(ps.data(), size, types.data());+  }+  return size;+}++template <typename T, typename Is = std::make_index_sequence<std::tuple_size<T>::value>>+uint32_t convArgsTupleToValTypes(std::vector<enum WasmEdge_ValType> &types) {+  return convArgsTupleToValTypesImpl<T>(types, Is());+}++/// Helper templates to create WasmEdge_FunctionTypeContext.+template <typename R, typename T> WasmEdge_FunctionTypeContext *newWasmEdgeFuncType() {+  std::vector<enum WasmEdge_ValType> params, returns;+  uint32_t param_nums = convArgsTupleToValTypes<T>(params);+  uint32_t return_nums = convArgsTupleToValTypes<std::tuple<R>>(returns);+  auto *ftype = WasmEdge_FunctionTypeCreate(params.data(), param_nums, returns.data(), return_nums);+  return ftype;+}++template <typename T> WasmEdge_FunctionTypeContext *newWasmEdgeFuncType() {+  std::vector<enum WasmEdge_ValType> params;+  uint32_t param_nums = convArgsTupleToValTypes<T>(params);+  auto *ftype = WasmEdge_FunctionTypeCreate(params.data(), param_nums, nullptr, 0);+  return ftype;+}++} // namespace++namespace proxy_wasm {+namespace WasmEdge {++struct HostFuncData {+  HostFuncData(const std::string_view modname, const std::string_view name)+      : modname_(modname), name_(name) {}+  ~HostFuncData() { WasmEdge_FunctionTypeDelete(functype_); }++  std::string modname_, name_;+  WasmEdge_WrapFunc_t callback_;+  WasmEdge_FunctionTypeContext *functype_;+  void *raw_func_;+  WasmVm *vm_;+};++using HostFuncDataPtr = std::unique_ptr<HostFuncData>;++struct HostModuleData {+  HostModuleData(const std::string_view modname) {+    cxt_ =+        WasmEdge_ImportObjectCreate(WasmEdge_StringWrap(modname.data(), modname.length()), nullptr);+  }+  ~HostModuleData() { WasmEdge_ImportObjectDelete(cxt_); }++  WasmEdge_ImportObjectContext *cxt_;+};++using HostModuleDataPtr = std::unique_ptr<HostModuleData>;++class WasmEdge : public WasmVm {+public:+  WasmEdge() {+    loader_ = WasmEdge_LoaderCreate(nullptr);+    validator_ = WasmEdge_ValidatorCreate(nullptr);+    interpreter_ = WasmEdge_InterpreterCreate(nullptr, nullptr);+    store_ = nullptr;+    module_ = nullptr;+    memory_ = nullptr;+  }++  std::string_view runtime() override { return "wasmedge"; }+  std::string_view getPrecompiledSectionName() override { return ""; }++  Cloneable cloneable() override { return Cloneable::NotCloneable; }+  std::unique_ptr<WasmVm> clone() override { return nullptr; }++  bool load(std::string_view bytecode, std::string_view precompiled,+            const std::unordered_map<uint32_t, std::string> function_names) override;+  bool link(std::string_view debug_name) override;+  uint64_t getMemorySize() override;+  std::optional<std::string_view> getMemory(uint64_t pointer, uint64_t size) override;+  bool setMemory(uint64_t pointer, uint64_t size, const void *data) override;+  bool getWord(uint64_t pointer, Word *word) override;+  bool setWord(uint64_t pointer, Word word) override;+  size_t getWordSize() override { return sizeof(uint32_t); };++#define _REGISTER_HOST_FUNCTION(T)                                                                 \+  void registerCallback(std::string_view module_name, std::string_view function_name, T,           \+                        typename ConvertFunctionTypeWordToUint32<T>::type f) override {            \+    registerHostFunctionImpl(module_name, function_name, f);                                       \+  };+  FOR_ALL_WASM_VM_IMPORTS(_REGISTER_HOST_FUNCTION)+#undef _REGISTER_HOST_FUNCTION++#define _GET_MODULE_FUNCTION(T)                                                                    \+  void getFunction(std::string_view function_name, T *f) override {                                \+    getModuleFunctionImpl(function_name, f);                                                       \+  };+  FOR_ALL_WASM_VM_EXPORTS(_GET_MODULE_FUNCTION)+#undef _GET_MODULE_FUNCTION+private:+  template <typename... Args>+  void registerHostFunctionImpl(std::string_view module_name, std::string_view function_name,+                                void (*function)(Args...));++  template <typename R, typename... Args>+  void registerHostFunctionImpl(std::string_view module_name, std::string_view function_name,+                                R (*function)(Args...));++  template <typename... Args>+  void getModuleFunctionImpl(std::string_view function_name,+                             std::function<void(ContextBase *, Args...)> *function);++  template <typename R, typename... Args>+  void getModuleFunctionImpl(std::string_view function_name,+                             std::function<R(ContextBase *, Args...)> *function);++  WasmEdgeLoaderPtr loader_;+  WasmEdgeValidatorPtr validator_;+  WasmEdgeInterpreterPtr interpreter_;+  WasmEdgeStorePtr store_;+  WasmEdgeASTModulePtr module_;+  WasmEdge_MemoryInstanceContext *memory_;++  std::unordered_map<std::string, HostFuncDataPtr> host_functions_;+  std::unordered_map<std::string, HostModuleDataPtr> import_objects_;+  std::unordered_set<std::string> module_functions_;+};++bool WasmEdge::load(std::string_view bytecode, std::string_view,+                    const std::unordered_map<uint32_t, std::string>) {+  WasmEdge_ASTModuleContext *mod = nullptr;+  WasmEdge_Result res = WasmEdge_LoaderParseFromBuffer(+      loader_.get(), &mod, reinterpret_cast<const uint8_t *>(bytecode.data()), bytecode.size());+  if (WasmEdge_ResultOK(res)) {+    res = WasmEdge_ValidatorValidate(validator_.get(), mod);+  }+  if (WasmEdge_ResultOK(res)) {+    module_ = mod;+  }+  return WasmEdge_ResultOK(res);+}++bool WasmEdge::link(std::string_view debug_name) {+  assert(module_ != nullptr);++  /// Create store and register imports.

Nit: C++ uses // for comments, not /// (same in other places).

q82419

comment created time in 17 days

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Add the WasmEdge runtime supporting.

 #if defined(PROXY_WASM_HAS_RUNTIME_WAMR) #include "include/proxy-wasm/wamr.h" #endif+#if defined(PROXY_WASM_HAS_RUNTIME_WASMEDGE)+#include "include/proxy-wasm/wasmedge.h"+#endif

Nit: sort alphabethically among runtimes.

q82419

comment created time in 17 days

PullRequestReviewEvent

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Add the WasmEdge runtime supporting.

 def proxy_wasm_select_runtime_wavm(xs):         "@proxy_wasm_cpp_host//bazel:runtime_wavm": xs,         "//conditions:default": [],     })++def proxy_wasm_select_runtime_wasmedge(xs):+    return select({+        "@proxy_wasm_cpp_host//bazel:runtime_wasmedge": xs,+        "//conditions:default": [],+    })

Nit: sort alphabethically among runtimes.

q82419

comment created time in 17 days

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Add the WasmEdge runtime supporting.

 config_setting(     name = "runtime_wavm",     values = {"define": "runtime=wavm"}, )++config_setting(+    name = "runtime_wasmedge",+    values = {"define": "runtime=wasmedge"},+)

Nit: sort alphabethically among runtimes.

q82419

comment created time in 17 days

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Add the WasmEdge runtime supporting.

 cc_library(         [":wasmtime_lib"],     ) + proxy_wasm_select_runtime_wavm(         [":wavm_lib"],+    ) + proxy_wasm_select_runtime_wasmedge(+        [":wasmedge_lib"],

Nit: sort alphabethically among runtimes.

q82419

comment created time in 17 days

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Add the WasmEdge runtime supporting.

 cc_library(     ], ) +cc_library(+    name = "wasmedge_lib",

Nit: sort alphabethically among runtimes.

q82419

comment created time in 17 days

PullRequestReviewEvent

Pull request review commentbytecodealliance/rfcs

RFC: Wasmtime 1.0

+# Summary++[summary]: #summary++This RFC is a proposal to release Wasmtime with a 1.0 version. In doing so this+proposal also defines what it means to be 1.0 and details areas such as:++* What is Wasmtime's stability story.+* What will Wasmtime's release process be.+* What users can expect from Wasmtime going forward.++# Motivation+[motivation]: #motivation++Wasmtime has for quite some time been "production ready" in the sense that it's+actually used in production and the technical implementation is reliable enough+to use. There are a number of points which may cause users to be hesitant to use+Wasmtime in production, however, including:++* Wasmtime's literal version number is in the "pre-release" phase (it's 0.29.0+  at the time of this writing). The lack of digit in the "major" spot can deter+  folks by giving off a perception that Wasmtime isn't ready for+  production use yet. While this is somewhat normal in the Rust ecosystem to+  have battle-hardened crates in the 0.x.y phase, this is much less normal in+  the broader software-in-general ecosystem.++* Wasmtime does not have a clear commitment to stability at this time. We have+  the RFC process for big changes but it's not clearly defined otherwise when+  and where Wasmtime may change its APIs. This means that users considering+  Wasmtime for long-term use don't have a good idea of what to expect from the+  Wasmtime project in the long-term in terms of maintenance and updates.++* Wasmtime does not currently have a formal release schedule or process.+  Releases are currently somewhat ad-hoc "when we feel like it". While this has+  worked well enough for now it's not necessarily good enough to rely on since+  users don't know when to expect new features to be released or what the+  release cadence might look like.++* Wasmtime does not have a well-defined process for which releases are supported+  and which receive fixes. For example with [CVE-2021-32629][cve] we backported+  fixes to the previous stable release of Wasmtime, but not others. This was+  done in an ad-hoc and not well-defined manner, and isn't the best way to do+  this moving forward.++The motivation for this RFC is to effectively fix all these issues. Wasmtime is,+as a codebase, technically ready for use in production. This RFC intends to+cover the rest of the ground necessary to make Wasmtime suitable for production+use, mostly on process-aspects and such. Once this RFC is implemented we, as+project maintainers, and users, as developers using Wasmtime, should all be+confident that Wasmtime feels "1.0" and is production ready in all aspects.++Many projects in the open source ecosystem are "production ready" and can serve+as inspiration to draw from for each of the above points. Release processes for+various projects can widely differ and serve different goals for both+maintainers and users. What's appropriate for one project doesn't necessarily+mean that it's also appropriate for Wasmtime itself. This proposal upholds a+number of goals that are specific to Wasmtime itself and how it's expected+Wasmtime will be used:++* Wasmtime should be released to users in a predictable fashion. For example+  "when will this feature be released?" should be easy to answer.++* Users should have a clear expectation for support of older versions of+  Wasmtime. For example "does this version get bug fixes and security fixes?"+  should be easy to answer.++* Users should be able to clearly understand what it means to keep up with+  Wasmtime and its development, and users should be able to easily upgrade+  between Wasmtime versions. For example "how do I get the latest version?" or+  "how do I upgrade from my current version?" should be easy to answer.++* Developers of Wasmtime should not be hindered by processes to land+  improvements to Wasmtime. For example "when can I land my 10% perf increase+  that tweaks APIs" should be easy to answer, and the answer shouldn't be+  "six months from now". Furthermore bugfixes which may break APIs should also+  not be difficult to land.++* Users should be able to clearly understand what version of Wasmtime they're+  using. It's possible to use Wasmtime through a variety of means such as the+  numerous embedding APIs for each language, and it should always be clear what+  version of the project you're using.++The constraints here do not map perfectly to what other projects do all the+time. For example Wasmtime will not have as strong of a committment to API+stability as the Rust language and standard library. Wasmtime does want,+however, to maintain the "largely hassle-free upgrade" experience inspired by+Rust's example, though. This proposal attempts to identify the right balance+between these various concerns for the Wasmtime project itself.++[cve]: https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5++# Proposal+[proposal]: #proposal++A comprehensive 1.0 release story for Wasmtime comprises of a number of+inter-related parts, many of which can greatly affect how the others are+organized. This proposal is broken down into a number of sub-parts, but it's+recommended to read through all of them to get a good idea of how they're all+related.++## Stability and Future Development++Wasmtime is an implementation of a WebAssembly runtime. The actual+implementation of Wasmtime is ever-changing and ever-improving as better ways of+implementing previous constructs are discovered. Furthermore WebAssembly itself+is ever-changing and ever-improving where there are almost always active+proposals in flight to extend and modify WebAssembly. The nature of Wasmtime and+its goals mean that **Wasmtime's stability story will not include API stability+in the literal sense of "Wasmtime will always be 1.0 and never 2.0"**.++For Rust users this may feel a bit discombobulating where Rust is likely to+always be "1.x". This isn't viable for Wasmtime: the addition of new WebAssembly+features will often require breaking API compatibility, so we don't have much+choice in the matter. The ability to break API compatibility also enables+improvements to the runtime that wouldn't be possible without changes to the+embedding API. These are seen as critical abilities needed to improve Wasmtime+over time. As mentioned in the motivation section, Wasmtime developers themselves+should not feel overly burdened or having to contort their code to land changes+which are seen as important. Allowing breaking changes is seen as key to enabling+this.++Naturally, though, the world is not entirely made up of Wasmtime developers.+Instead it's much more likely that the number of users of Wasmtime far+outweighs the number of developers on Wasmtime. A stream of constant breaking+changes makes it feel harder to use Wasmtime since it can feel more difficult to+keep up with the latest and receive bug fixes and new features. Wasmtime's+stability story, consequently, will not be on the end of the spectrum where+breaking changes are landed willy-nilly. This means that there's a tension set+up between developers of Wasmtime and users of Wasmtime, but this is to be+expected from the stable release of a project.++On a spectrum of "Wasmtime never breaks any API ever" to "Wasmtime breaks all+its APIs every release" Wasmtime will reside towards the first half here. In+other words Wasmtime developers will be expected to rarely and deliberately+break existing APIs, but will also be allowed to break APIs as necessary. The+major goal here is "hassle-free upgrades" inspired by the Rust release process+where API stability in the absolute literal sense is detrimental to the+development of Wasmtime, but deliberate effort and work is done to ensure+upgrades are as seamless as possible.++Users should expect that they will regularly need to increase the major version+of Wasmtime to upgrade Wasmtime usage in their projects. Furthermore users+should expect that between upgrades they may need to tweak some APIs and update+them to continue to use the latest-and-greatest Wasmtime. At the same time+though users should expect that they will not be blindsided by major+refactorings. For example changes like [Wasmtime's new API][new-api] will still+go through the RFC process and will be deliberately scheduled and widely+advertised before they're released. Note also that changes of that magnitude are+expected to be quite rare.++[new-api]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/new-api.md++## What is being stabilized?++Wasmtime is a relatively large project at this point with lots of components.+Additionally not everything lives in the `wasmtime` repository itself but there+are separate dependencies such as `wasm-tools`, `wasmtime-*` embeddings,+`witx-bindgen`, etc. This proposal does not attempt to blindly label everything+with 1.0 and ship it, but rather discrete "tiers" of support are defined for+what it means to use a component of the Wasmtime project.++At a base level anything shipped in Wasmtime is guaranteed to clear a minimum+threshold of quality. All dependencies, even the transitive ones, used by+Wasmtime are guaranteed to be "production quality" for the surface area that+Wasmtime uses. On the other hand, though, not all of Wasmtime's dependencies+and components will meet the same level of API stability expected of a stable+project. For example Cranelift is not an API-stable component that will be+released with Wasmtime. For now Cranelift will likely have the same release+cadence of Wasmtime for ease of infrastructure, but this may change in the+future as Cranelift develops its own API and release process. Additionally,+though, the internal crates of the `wasmtime` implementation, such as+`wasmtime-runtime`, are not intended to ever be API-stable but are intended to+be production quality.++Public-facing components of Wasmtime that users are expected to use will be+classified into three different tiers of support. These tiers are defined by the+stability of the API users can expect as well as the quality of implementation+they can expect. The tiers are organized into the best-supported to+least-supported order, with components in tier 1 being the best supported. Note+that as mentioned above internal dependencies of Wasmtime, such as Cranelift,+`wasmtime-*` internal dependencies, or `wasm-tools` crates, are not classified+in these tiers because they are not intended to be public-facing parts of the+Wasmtime project that users use.++#### Tier 1 - API stable, production quality++The highest tier, similar to Rust's "tier 1 platforms" is defined as the highest+level of support and stability for Wasmtime components. Components that are tier+1 are expected to at least meet this criteria:++* API stable - this does not mean "forever stable" but it does mean that major+  breaking changes are rare.+* RFCs required for major changes - all large changes to the API or+  functionality will require an RFC to be approved.+* Well-maintained - at least one member of the Bytecode Alliance is actively+  maintaining this component and providing it with security updates, bug fixes,+  and new feature development.+* Released with Wasmtime - these components are all released on the same cadence+  as the rest of the Wasmtime project (more on this cadence later).+* Production quality - this component is well vetted and reviewed by multiple+  developers. Landing changes requires code review and extensive test suites to+  pass.++At the time of this RFC, the only component in the Wasmtime ecosystem which+meets these criteria is the `wasmtime` Rust crate itself. This tier is intended+to be quite strict in terms of requirements and nontrivial to reach, and the+other components of Wasmtime today do not yet currently meet all of these+requirements and consequently will fall into lower tiers.++#### Tier 2 - API unstable, production quality++This second tier of support differentiates itself from tier 1 components not+requiring as much API stability. The same level of production quality for code+and implementation, however, is expected of tier 2 components. The checklist for+this tier is:++* API unstable - strict API stability is not required at this time. Components+  can freely have major changes to their API without much warning. This is+  intended to be an incubation area for production quality implementations which+  haven't yet necessarily had enough experience to determine the best API yet.+  Additionally RFCs are not required for changes in this tier.+* Well-maintained - same as tier 1.+* Released with Wasmtime - same as tier 1.+* Production quality - same as tier 1.++Wasmtime components that fall into this category are the C API of Wasmtime and+the `wasmtime-wasi` crate. In both of these cases the API stability isn't quite+there yet, but both are well-reviewed and production quality.++Note that no language bindings are yet to the Tier 2 level yet. This is+intentional and discussed in the next section.++### Tier 3 - API unstable, not guaranteed production-ready++This is the lowest of the tiers of supported APIs for Wasmtime and is intended+to be a sort of "catch-all" for everything that doesn't fall into the above+tiers. This tier does not come with many guarantees associated with it, and is+intended to be a breeding ground and call-for-help for components to reach tier+2 or higher status.++Components in tier 3 may still meet various requirements of tier 1 and 2 while+still being classified as tier 3. For example components here may not have code+review but could still be of a high-enough quality to use in production.+Similarly they might be released at the same cadence of Wasmtime itself but+lacking in API stability.++Today this tier includes:++* `wasmtime-py` - Python bindings for Wasmtime+* `wasmtime-go` - Go bindings for Wasmtime+* `wasmtime-dotnet` - .NET bindings for Wasmtime+* `wasmtime-cpp` - C++ bindings for Wasmtime+* `witx-bindgen` - Canonical API bindings generator for Interface Types

Right, at the same time, for someone using witx-bindgen only to generate guest bindings, seeing "random" major version bumps without any significant changes in witx-bindgen might be a weird experience.

alexcrichton

comment created time in 17 days

PullRequestReviewEvent

Pull request review commentbytecodealliance/rfcs

RFC: Wasmtime 1.0

+# Summary++[summary]: #summary++This RFC is a proposal to release Wasmtime with a 1.0 version. In doing so this+proposal also defines what it means to be 1.0 and details areas such as:++* What is Wasmtime's stability story.+* What will Wasmtime's release process be.+* What users can expect from Wasmtime going forward.++# Motivation+[motivation]: #motivation++Wasmtime has for quite some time been "production ready" in the sense that it's+actually used in production and the technical implementation is reliable enough+to use. There are a number of points which may cause users to be hesitant to use+Wasmtime in production, however, including:++* Wasmtime's literal version number is in the "pre-release" phase (it's 0.29.0+  at the time of this writing). The lack of digit in the "major" spot can deter+  folks by giving off a perception that Wasmtime isn't ready for+  production use yet. While this is somewhat normal in the Rust ecosystem to+  have battle-hardened crates in the 0.x.y phase, this is much less normal in+  the broader software-in-general ecosystem.++* Wasmtime does not have a clear commitment to stability at this time. We have+  the RFC process for big changes but it's not clearly defined otherwise when+  and where Wasmtime may change its APIs. This means that users considering+  Wasmtime for long-term use don't have a good idea of what to expect from the+  Wasmtime project in the long-term in terms of maintenance and updates.++* Wasmtime does not currently have a formal release schedule or process.+  Releases are currently somewhat ad-hoc "when we feel like it". While this has+  worked well enough for now it's not necessarily good enough to rely on since+  users don't know when to expect new features to be released or what the+  release cadence might look like.++* Wasmtime does not have a well-defined process for which releases are supported+  and which receive fixes. For example with [CVE-2021-32629][cve] we backported+  fixes to the previous stable release of Wasmtime, but not others. This was+  done in an ad-hoc and not well-defined manner, and isn't the best way to do+  this moving forward.++The motivation for this RFC is to effectively fix all these issues. Wasmtime is,+as a codebase, technically ready for use in production. This RFC intends to+cover the rest of the ground necessary to make Wasmtime suitable for production+use, mostly on process-aspects and such. Once this RFC is implemented we, as+project maintainers, and users, as developers using Wasmtime, should all be+confident that Wasmtime feels "1.0" and is production ready in all aspects.++Many projects in the open source ecosystem are "production ready" and can serve+as inspiration to draw from for each of the above points. Release processes for+various projects can widely differ and serve different goals for both+maintainers and users. What's appropriate for one project doesn't necessarily+mean that it's also appropriate for Wasmtime itself. This proposal upholds a+number of goals that are specific to Wasmtime itself and how it's expected+Wasmtime will be used:++* Wasmtime should be released to users in a predictable fashion. For example+  "when will this feature be released?" should be easy to answer.++* Users should have a clear expectation for support of older versions of+  Wasmtime. For example "does this version get bug fixes and security fixes?"+  should be easy to answer.++* Users should be able to clearly understand what it means to keep up with+  Wasmtime and its development, and users should be able to easily upgrade+  between Wasmtime versions. For example "how do I get the latest version?" or+  "how do I upgrade from my current version?" should be easy to answer.++* Developers of Wasmtime should not be hindered by processes to land+  improvements to Wasmtime. For example "when can I land my 10% perf increase+  that tweaks APIs" should be easy to answer, and the answer shouldn't be+  "six months from now". Furthermore bugfixes which may break APIs should also+  not be difficult to land.++* Users should be able to clearly understand what version of Wasmtime they're+  using. It's possible to use Wasmtime through a variety of means such as the+  numerous embedding APIs for each language, and it should always be clear what+  version of the project you're using.++The constraints here do not map perfectly to what other projects do all the+time. For example Wasmtime will not have as strong of a committment to API+stability as the Rust language and standard library. Wasmtime does want,+however, to maintain the "largely hassle-free upgrade" experience inspired by+Rust's example, though. This proposal attempts to identify the right balance+between these various concerns for the Wasmtime project itself.++[cve]: https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5++# Proposal+[proposal]: #proposal++A comprehensive 1.0 release story for Wasmtime comprises of a number of+inter-related parts, many of which can greatly affect how the others are+organized. This proposal is broken down into a number of sub-parts, but it's+recommended to read through all of them to get a good idea of how they're all+related.++## Stability and Future Development++Wasmtime is an implementation of a WebAssembly runtime. The actual+implementation of Wasmtime is ever-changing and ever-improving as better ways of+implementing previous constructs are discovered. Furthermore WebAssembly itself+is ever-changing and ever-improving where there are almost always active+proposals in flight to extend and modify WebAssembly. The nature of Wasmtime and+its goals mean that **Wasmtime's stability story will not include API stability+in the literal sense of "Wasmtime will always be 1.0 and never 2.0"**.++For Rust users this may feel a bit discombobulating where Rust is likely to+always be "1.x". This isn't viable for Wasmtime: the addition of new WebAssembly+features will often require breaking API compatibility, so we don't have much+choice in the matter. The ability to break API compatibility also enables+improvements to the runtime that wouldn't be possible without changes to the+embedding API. These are seen as critical abilities needed to improve Wasmtime+over time. As mentioned in the motivation section, Wasmtime developers themselves+should not feel overly burdened or having to contort their code to land changes+which are seen as important. Allowing breaking changes is seen as key to enabling+this.++Naturally, though, the world is not entirely made up of Wasmtime developers.+Instead it's much more likely that the number of users of Wasmtime far+outweighs the number of developers on Wasmtime. A stream of constant breaking+changes makes it feel harder to use Wasmtime since it can feel more difficult to+keep up with the latest and receive bug fixes and new features. Wasmtime's+stability story, consequently, will not be on the end of the spectrum where+breaking changes are landed willy-nilly. This means that there's a tension set+up between developers of Wasmtime and users of Wasmtime, but this is to be+expected from the stable release of a project.++On a spectrum of "Wasmtime never breaks any API ever" to "Wasmtime breaks all+its APIs every release" Wasmtime will reside towards the first half here. In+other words Wasmtime developers will be expected to rarely and deliberately+break existing APIs, but will also be allowed to break APIs as necessary. The+major goal here is "hassle-free upgrades" inspired by the Rust release process+where API stability in the absolute literal sense is detrimental to the+development of Wasmtime, but deliberate effort and work is done to ensure+upgrades are as seamless as possible.++Users should expect that they will regularly need to increase the major version+of Wasmtime to upgrade Wasmtime usage in their projects. Furthermore users+should expect that between upgrades they may need to tweak some APIs and update+them to continue to use the latest-and-greatest Wasmtime. At the same time+though users should expect that they will not be blindsided by major+refactorings. For example changes like [Wasmtime's new API][new-api] will still+go through the RFC process and will be deliberately scheduled and widely+advertised before they're released. Note also that changes of that magnitude are+expected to be quite rare.++[new-api]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/new-api.md++## What is being stabilized?++Wasmtime is a relatively large project at this point with lots of components.+Additionally not everything lives in the `wasmtime` repository itself but there+are separate dependencies such as `wasm-tools`, `wasmtime-*` embeddings,+`witx-bindgen`, etc. This proposal does not attempt to blindly label everything+with 1.0 and ship it, but rather discrete "tiers" of support are defined for+what it means to use a component of the Wasmtime project.++At a base level anything shipped in Wasmtime is guaranteed to clear a minimum+threshold of quality. All dependencies, even the transitive ones, used by+Wasmtime are guaranteed to be "production quality" for the surface area that+Wasmtime uses. On the other hand, though, not all of Wasmtime's dependencies+and components will meet the same level of API stability expected of a stable+project. For example Cranelift is not an API-stable component that will be+released with Wasmtime. For now Cranelift will likely have the same release+cadence of Wasmtime for ease of infrastructure, but this may change in the+future as Cranelift develops its own API and release process. Additionally,+though, the internal crates of the `wasmtime` implementation, such as+`wasmtime-runtime`, are not intended to ever be API-stable but are intended to+be production quality.++Public-facing components of Wasmtime that users are expected to use will be+classified into three different tiers of support. These tiers are defined by the+stability of the API users can expect as well as the quality of implementation+they can expect. The tiers are organized into the best-supported to+least-supported order, with components in tier 1 being the best supported. Note+that as mentioned above internal dependencies of Wasmtime, such as Cranelift,+`wasmtime-*` internal dependencies, or `wasm-tools` crates, are not classified+in these tiers because they are not intended to be public-facing parts of the+Wasmtime project that users use.++#### Tier 1 - API stable, production quality++The highest tier, similar to Rust's "tier 1 platforms" is defined as the highest+level of support and stability for Wasmtime components. Components that are tier+1 are expected to at least meet this criteria:++* API stable - this does not mean "forever stable" but it does mean that major+  breaking changes are rare.+* RFCs required for major changes - all large changes to the API or+  functionality will require an RFC to be approved.+* Well-maintained - at least one member of the Bytecode Alliance is actively+  maintaining this component and providing it with security updates, bug fixes,+  and new feature development.+* Released with Wasmtime - these components are all released on the same cadence+  as the rest of the Wasmtime project (more on this cadence later).+* Production quality - this component is well vetted and reviewed by multiple+  developers. Landing changes requires code review and extensive test suites to+  pass.++At the time of this RFC, the only component in the Wasmtime ecosystem which+meets these criteria is the `wasmtime` Rust crate itself. This tier is intended+to be quite strict in terms of requirements and nontrivial to reach, and the+other components of Wasmtime today do not yet currently meet all of these+requirements and consequently will fall into lower tiers.++#### Tier 2 - API unstable, production quality++This second tier of support differentiates itself from tier 1 components not+requiring as much API stability. The same level of production quality for code+and implementation, however, is expected of tier 2 components. The checklist for+this tier is:++* API unstable - strict API stability is not required at this time. Components+  can freely have major changes to their API without much warning. This is+  intended to be an incubation area for production quality implementations which+  haven't yet necessarily had enough experience to determine the best API yet.+  Additionally RFCs are not required for changes in this tier.+* Well-maintained - same as tier 1.+* Released with Wasmtime - same as tier 1.+* Production quality - same as tier 1.++Wasmtime components that fall into this category are the C API of Wasmtime and+the `wasmtime-wasi` crate. In both of these cases the API stability isn't quite+there yet, but both are well-reviewed and production quality.++Note that no language bindings are yet to the Tier 2 level yet. This is+intentional and discussed in the next section.++### Tier 3 - API unstable, not guaranteed production-ready++This is the lowest of the tiers of supported APIs for Wasmtime and is intended+to be a sort of "catch-all" for everything that doesn't fall into the above+tiers. This tier does not come with many guarantees associated with it, and is+intended to be a breeding ground and call-for-help for components to reach tier+2 or higher status.++Components in tier 3 may still meet various requirements of tier 1 and 2 while+still being classified as tier 3. For example components here may not have code+review but could still be of a high-enough quality to use in production.+Similarly they might be released at the same cadence of Wasmtime itself but+lacking in API stability.++Today this tier includes:++* `wasmtime-py` - Python bindings for Wasmtime+* `wasmtime-go` - Go bindings for Wasmtime+* `wasmtime-dotnet` - .NET bindings for Wasmtime+* `wasmtime-cpp` - C++ bindings for Wasmtime+* `witx-bindgen` - Canonical API bindings generator for Interface Types++Each of these projects is missing at least one criteria from the list of Tier 2+requirements. As is inherent to this tier, however, this is a call-for-support+for others who are interested in moving these projects up a tier of support. For+example most of these projects primarily need more maintainers to help review+bindings for language idioms and implementation, and that's all that's necessary+to move into tier 2.++It's also worth highlighting that the intent here is to establish a deliberately+high bar of quality we commit to. In many established open source projects, the+level of quality, and the development and reviewing practices some or all of+these components have and use would be deemed "good enough". And in many domains+they might be. We're acutely aware of Wasmtime's, and more generally+WebAssembly's use in mission- and security-critical environments, and we believe+that we need to hold ourselves to higher standards accordingly.++## What does it mean for a feature to be stable?++The tiers of support for Wasmtime are primarily concerned with the APIs that+users interact with and the support expected there, but Wasmtime is also+defined by the stability of its implementation. Features implemented in Wasmtime+itself are held to a high standard of quality which should fit into the+quality expectations of components that are tier 1. Features enabled-by-default+and implemented in Wasmtime are expected to meet some baseline criteria:++* The feature must be throughly tested in Wasmtime's CI on major platforms (at+  this time x86\_64 and AArch64)++* If the feature is for a WebAssembly upstream proposal, all spec tests must be+  enabled and passing and the proposal must be in [stage 4 or+  later](https://github.com/WebAssembly/meetings/blob/main/process/phases.md).++* The feature must have no open questions, design concerns, or serious known+  bugs.++* The feature must have support in fuzzers and have been fuzzed for at least a+  week. Additionally we should be confident that the fuzzing support for this+  feature is exercising the necessary bits in Wasmtime thoroughly.++* The feature is supported in the Rust API, the C API, and at least one other+  language's embedding API.++* A member of the Bytecode Alliance must be "on the hook" for maintenance of+  this feature.++Features can be implemented in-tree even if they do not meet these criteria but+the features must be disabled-by-default at either runtime or compile+time. If a feature's interim implementation does not have an undue compile-time+or runtime footprint then it can be off-by-default at runtime but compiled in by+default. If, however, an in-progress feature has a significant compile-time or+runtime footprint it must be disabled at compile-time by default.++Features implemented in-tree but not currently stabilized are also subject to+removal if there is no active progress being made on the feature. For example if+this RFC is approved **the `lightbeam` feature of Wasmtime would be removed**.++> **Note**: This RFC proposes removing `lightbeam` because it isn't actively+> maintained, and as a result hasn't been compiling successfully for quite+> some time. The Wasmtime project is still interested in the addition of a+> baseline compiler, but the addition of one would be proposed in an RFC and+> undergo careful evaluation to ensure the design aligns with Wasmtime's+> goals and requirements, and the compiler has a solid maintenance story.++## Release Process and Cadence++Wasmtime intends to follow in the footsteps of many other projects on the matter+of release cadence with a frequent and predictable release cycle. **This RFC+proposes releasing Wasmtime on Tuesday every 4 weeks**. The precise date of+each release may be adjusted to avoid coinciding with public holidays, though,+which could result in some releases being a slightly different width apart.++The goal is to publish work and improvements in Wasmtime on a relatively rapid+schedule to ensure that the latest-and-greatest is available for usage. This is+also intended to signal to users that consumers of Wasmtime should expect to+stay up-to-date with Wasmtime and it's not appropriate to ossify a version for+years and expect it to continue to work and receive everlasting maintenance.++Each release of Wasmtime will bump the major version number of Wasmtime itself.+This means, for example, that Wasmtime 2.0 will be released one month after+Wasmtime 1.0. After one year Wasmtime will be at 12.0. At this time it is not+planned that "minor" releases will be made of the 1.1.0 variety. Note that this+means means that not all major releases will actually contain breaking changes.+The reason we propose to nevertheless always bump the major version is that this+allows us to keep Wasmtime's version number in sync with that of its various+language-specific embeddings: as a developer using Wasmtime, you shouldn't have+to worry about how how the version number of your language's Wasmtime embedding+lines up with that of Wasmtime itself. E.g., if you use`wasmtime-py 7.0`, you+can be sure that you're using Wasmtime 7.0. Trying to keep major version bumps+to a minimum while keeping version numbers aligned would force us to still bump+Wasmtime's and all embeddings' version numbers whenever there's a breaking+change in even a single language-specific embedding. As noted in the previous+section, though, each release is expected to be a relatively hassle-free+upgrade, so while API-breaking changes are allowed they're not necessarily+encouraged.++Wasmtime will continue to create a tag for all released versions of Wasmtime+with a corresponding GitHub release as is done today for the CLI and C API+binaries. Embeddings will all be tagged and released as appropriate to+language-specific package managers (such as crates.io and PyPI). Wasmtime will+always be released from the `main` branch of the Wasmtime repository itself,+which means that all development is happening on `main` and once something lands+it's guaranteed to be in the next release. Note that bug fixes and such for+historical releases are discussed later in this proposal.++Releasing a new version of Wasmtime every 4 weeks can be quite rapid for some+users who don't necessarily want to stay up-to-date with the latest and greatest+of Wasmtime, but still want the stability of a production-ready WebAssembly+runtime. For these users, this leads well into the next section ...++### Long-term Support Releases++Wasmtime will support some releases for an extended period of time relative to+other releases. These releases will be known as "long term support" releases or+LTS releases. **Wasmtime will support two active LTS versions at any point in

I meant the cost of backporting fixes, which often means rewriting the change from scratch, since trivial cherry-picks to a branch from a few months ago rarely work in an actively developed codebase... Having said that, I'm not very familiar with the codebase or the development pace of Wasmtime, so perhaps that won't be an issue.

alexcrichton

comment created time in 17 days

PullRequestReviewEvent

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Adds verification key for Wasm module

 using WasmHandleCloneFactory =     std::function<std::shared_ptr<WasmHandleBase>(std::shared_ptr<WasmHandleBase> wasm)>;  // Returns nullptr on failure (i.e. initialization of the VM fails).+// TODO: Consider a VerificationOptions struct rather than a single pubkey.

s/TODO/TODO(asraa)/

asraa

comment created time in 17 days

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Adds verification key for Wasm module

  namespace proxy_wasm { -TEST(TestSignatureUtil, GoodSignature) {+std::string BytesToHex(std::vector<uint8_t> bytes) {
static std::string bytesToHex(std::vector<uint8_t> bytes) {
asraa

comment created time in 17 days

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Adds verification key for Wasm module

  namespace proxy_wasm { -TEST(TestSignatureUtil, GoodSignature) {+std::string BytesToHex(std::vector<uint8_t> bytes) {+  static const char *const hex = "0123456789ABCDEF";+  std::string result;+  result.reserve(bytes.size() * 2);+  for (auto byte : bytes) {+    result.push_back(hex[byte >> 4]);+    result.push_back(hex[byte & 0xf]);+  }+  return result;+}++static std::string publickey(std::string filename) {
static std::string publicKey(std::string filename) {
asraa

comment created time in 17 days

PullRequestReviewEvent

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Adds verification key for Wasm module

 class SignatureUtil {    * @param message is the reference to store the message (success or error).    * @return indicates whether the bytecode has a valid Wasm signature.    */-  static bool verifySignature(std::string_view bytecode, std::string &message);+  static bool verifySignature(std::string_view bytecode, const std::string pubkey, std::string &message);

Style: clang-format warning (line too long).

asraa

comment created time in 17 days

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Adds verification key for Wasm module

 template <size_t N> constexpr std::array<uint8_t, N> hex2pubkey(const char (&hex   return pubkey; } +std::optional<std::array<uint8_t, 32>> getEd25519PubKey(std::string pubkey) {+#ifdef PROXY_WASM_VERIFY_WITH_ED25519_PUBKEY+  static const auto ed25519_pubkey = hex2pubkey<32>(PROXY_WASM_VERIFY_WITH_ED25519_PUBKEY);+  return ed25519_pubkey;+#else+  if (!pubkey.empty()) {+    char pubkey_char[65];+    strcpy(pubkey_char, pubkey.c_str());+    return hex2pubkey<32>(pubkey_char);

hex2pubkey is a constexpr template written to decode hex literal at the build-time with zero-cost at runtime.

But if you have to copy all the bytes to use it, then it kind of misses the point, and it would be better to add hexstr2pubkey function that can decode it in a single pass (basically, a runtime equivalent of hex2pubkey).

asraa

comment created time in 17 days

Pull request review commentproxy-wasm/proxy-wasm-cpp-host

Adds verification key for Wasm module

 using WasmHandleCloneFactory =     std::function<std::shared_ptr<WasmHandleBase>(std::shared_ptr<WasmHandleBase> wasm)>;  // Returns nullptr on failure (i.e. initialization of the VM fails).+// TODO: Consider a VerificationOptions struct rather than a single pubkey. std::shared_ptr<WasmHandleBase>-createWasm(std::string vm_key, std::string code, std::shared_ptr<PluginBase> plugin,+    createWasm(std::string vm_key, std::string code, std::string pubkey,+               std::shared_ptr<PluginBase> plugin,

Style: clang-format warning (weird indent).

asraa

comment created time in 17 days