Mailing List Archive

I think not making WASM a first class concern in a proxy or server is missing out, more so in those platforms where extensibility isn't trivial. Apache will remain running in current setups but having limited extensibility is something concerning these days as systems are getting more and more complex. Writing an apache module isn't something you do every day and it probably takes quite some time, writing a wasm app following certain ABI is something you can do in minutes, hence supporting mod_wasm as a first class concern could be a good point in the sustainability of an ecosystem when it comes to moving forward out of the status quo.

On 2022/11/14 06:37:34 Jesús González wrote:
> Hi everyone,
>
>
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<https://wasmlabs.dev/>, a group focused on creating open source tools for WebAssembly.
>
> We have created mod_wasm, an Apache module for running WebAssembly binaries inside httpd, and we would like to contribute it upstream. Please see below for more details. We would love to get your feedback and understand what improvements would be needed (if any) before it could be considered for contribution to the project.
>
>
>
>
>
> The details:
>
>
>
> WebAssembly<https://webassembly.org/> (Wasm) is a new binary instruction format that is open, portable, efficient, secure, and polyglot. It originated in the browser but is increasingly used in server applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/).
>
>
>
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is similar to how mod_php embeds a PHP runtime to run PHP code. This enables any language that supports WebAssembly (including C++, Rust, Go but also Python, PHP, Ruby) to run with mod_wasm and take advantage of the extra level of security and sandboxing. To learn more about mod_wasm you can check out the following resources:
>
> * An overview article<https://wasmlabs.dev/articles/apache-mod-wasm/> for the original release.
> * We presented mod_wasm at ApacheCon this year and here are the slides<https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf> and the source code: https://github.com/vmware-labs/mod_wasm.
> * CNCF Talk on mod_wasm showcasing how to run WordPress: https://www.youtube.com/watch?v=jXe8kulUscQ
>
>
>
> In terms of mod_wasm architecture, the module is split into two parts:
>
> * mod_wasm.so is the extension module for Apache and it’s written in C.
> * An external dependency: libwasm_runtime.so, which is written in Rust and needs to be installed into the system.
>
>
>
> We modelled this after mod_tls, a module that is part of httpd and also has a Rust dependency.
>
> You can take a look at the architecture diagram and instructions on how to build the module here: https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
>
>
>
> In terms of the actual contribution, please find a patch attached. We tried to follow all existing conventions in terms of autoconf/automake, providing module documentation, etc. Please let us know anything that you see missing or could be improved. In particular, we do not know yet if it is better to keep the Rust code separate, as an external dependency (like mod_tls does) or in the Apache source code repository.
>
>
>
> In summary, we believe mod_wasm is a worthy addition to httpd and it will allow us to catch up to some of the other web servers already supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim Jagielski and Jean-Frederic Clere to submit it for contribution upstream and we are looking forward to your feedback.
>
>
>
> Cheers!
>
> Jesús
>
>
>
>
>

Huge fan, love that you are receptive to my feedback. If you get to the
point where the apreq_* (APR table-based) interfaces in trunk can be
exposed as read-only data structures in mod_wasm as an optional API for
power httpd users that like the sandboxed functionality you get OOTB, that
would justify a lot of the more conservative concerns that some devs have
for not putting incorporating this into the trunk codebase, which would be
my recommendation at that point for how to get it into a releasable tree at
some point.


On Tue, May 30, 2023 at 8:42?AM José Carlos Chávez <jcchavezs@apache.org>
wrote:

> I think not making WASM a first class concern in a proxy or server is
> missing out, more so in those platforms where extensibility isn't trivial.
> Apache will remain running in current setups but having limited
> extensibility is something concerning these days as systems are getting
> more and more complex. Writing an apache module isn't something you do
> every day and it probably takes quite some time, writing a wasm app
> following certain ABI is something you can do in minutes, hence supporting
> mod_wasm as a first class concern could be a good point in the
> sustainability of an ecosystem when it comes to moving forward out of the
> status quo.
>
> On 2022/11/14 06:37:34 Jesús González wrote:
> > Hi everyone,
> >
> >
> >
> > I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<
> https://wasmlabs.dev/>, a group focused on creating open source tools for
> WebAssembly.
> >
> > We have created mod_wasm, an Apache module for running WebAssembly
> binaries inside httpd, and we would like to contribute it upstream. Please
> see below for more details. We would love to get your feedback and
> understand what improvements would be needed (if any) before it could be
> considered for contribution to the project.
> >
> >
> >
> >
> >
> > The details:
> >
> >
> >
> > WebAssembly<https://webassembly.org/> (Wasm) is a new binary
> instruction format that is open, portable, efficient, secure, and polyglot.
> It originated in the browser but is increasingly used in server
> applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based
> plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/).
> >
> >
> >
> > mod_wasm is a way to run WebAssembly modules inside Apache Server. This
> is similar to how mod_php embeds a PHP runtime to run PHP code. This
> enables any language that supports WebAssembly (including C++, Rust, Go but
> also Python, PHP, Ruby) to run with mod_wasm and take advantage of the
> extra level of security and sandboxing. To learn more about mod_wasm you
> can check out the following resources:
> >
> > * An overview article<https://wasmlabs.dev/articles/apache-mod-wasm/>
> for the original release.
> > * We presented mod_wasm at ApacheCon this year and here are the
> slides<
> https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf>
> and the source code: https://github.com/vmware-labs/mod_wasm.
> > * CNCF Talk on mod_wasm showcasing how to run WordPress:
> https://www.youtube.com/watch?v=jXe8kulUscQ
> >
> >
> >
> > In terms of mod_wasm architecture, the module is split into two parts:
> >
> > * mod_wasm.so is the extension module for Apache and it’s written in
> C.
> > * An external dependency: libwasm_runtime.so, which is written in
> Rust and needs to be installed into the system.
> >
> >
> >
> > We modelled this after mod_tls, a module that is part of httpd and also
> has a Rust dependency.
> >
> > You can take a look at the architecture diagram and instructions on how
> to build the module here:
> https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
> >
> >
> >
> > In terms of the actual contribution, please find a patch attached. We
> tried to follow all existing conventions in terms of autoconf/automake,
> providing module documentation, etc. Please let us know anything that you
> see missing or could be improved. In particular, we do not know yet if it
> is better to keep the Rust code separate, as an external dependency (like
> mod_tls does) or in the Apache source code repository.
> >
> >
> >
> > In summary, we believe mod_wasm is a worthy addition to httpd and it
> will allow us to catch up to some of the other web servers already
> supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim
> Jagielski and Jean-Frederic Clere to submit it for contribution upstream
> and we are looking forward to your feedback.
> >
> >
> >
> > Cheers!
> >
> > Jesús
> >
> >
> >
> >
> >
>

Hi:

Can I be unsubscribed from this list?

Have sent previous messages following all the instructions on this page but
to no avail:
https://httpd.apache.org/userslist.html.


Best,

Dan

On Fri, Jan 27, 2023 at 11:36 AM Jesús González <jesusgm@vmware.com> wrote:

> Thanks Joe. You are correct, this initial implementation is the simplest
> one to get it off the ground. We plan to continue development and add the
> streaming functionality, which we know we will need for things like large
> PDF file generation or support for Proxy-Wasm.
>
>
>
> Yes, isolating language runtimes (PHP, Python, ...) per thread is a cool
> feature that enables new possibilities like simultaneously supporting
> multiple versions of PHP as well as better multi-tenancy (you will be able
> to keep user's code and assets separate from each other using Wasm built-in
> isolation mechanism).
>
>
>
> Regarding apreq, right now we have not had a need to use it as we pass
> most of the headers and body to the runtimes themselves as the language
> runtimes code for handling requests, etc. takes care of it as part of the
> CGI implementation, etc. As we look to add different functionality (i.e.
> extending Apache itself) we will probably provide access to it from Wasm.
>
>
>
>
>
> *De: *Joe Schaefer <joe@sunstarsys.com>
> *Responder a: *"dev@httpd.apache.org" <dev@httpd.apache.org>
> *Fecha: *jueves, 26 de enero de 2023, 5:17
> *Para: *"dev@httpd.apache.org" <dev@httpd.apache.org>
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
>
>
> Still, the idea is wicked cool if mod_wasm really can isolate the Python,
> PHP, etc targets onto individual POSIX threads.
>
>
>
> Very exciting stuff for HTTP/2 Webapps.
>

As per the instructions:

To unsubscribe, send a messages to *users-unsubscribe@httpd.apache.org
<users-unsubscribe@httpd.apache.org>* (or, if you are subscribed to the
digest version of the list, send to *users-digest-unsubscribe@httpd.apache.org
<users-digest-unsubscribe@httpd.apache.org>* ). You must send the
unsubscribe message from the same email address that you used to subscribe
to the list.

To complete the unsubscription process you must reply to a confirmation
email. If you do not receive this confirmation email, please check your
spam filters to see if they are capturing the message.


In this case, you would want to email dev-unsubscribe@httpd.apache.org





On Thu, Jun 1, 2023 at 4:32?PM Dan Ehrlich via dev <dev@httpd.apache.org>
wrote:

> Hi:
>
> Can I be unsubscribed from this list?
>
> Have sent previous messages following all the instructions on this page
> but to no avail:
> https://httpd.apache.org/userslist.html.
>
>
> Best,
>
> Dan
>
> On Fri, Jan 27, 2023 at 11:36 AM Jesús González <jesusgm@vmware.com>
> wrote:
>
>> Thanks Joe. You are correct, this initial implementation is the simplest
>> one to get it off the ground. We plan to continue development and add the
>> streaming functionality, which we know we will need for things like large
>> PDF file generation or support for Proxy-Wasm.
>>
>>
>>
>> Yes, isolating language runtimes (PHP, Python, ...) per thread is a cool
>> feature that enables new possibilities like simultaneously supporting
>> multiple versions of PHP as well as better multi-tenancy (you will be able
>> to keep user's code and assets separate from each other using Wasm built-in
>> isolation mechanism).
>>
>>
>>
>> Regarding apreq, right now we have not had a need to use it as we pass
>> most of the headers and body to the runtimes themselves as the language
>> runtimes code for handling requests, etc. takes care of it as part of the
>> CGI implementation, etc. As we look to add different functionality (i.e.
>> extending Apache itself) we will probably provide access to it from Wasm.
>>
>>
>>
>>
>>
>> *De: *Joe Schaefer <joe@sunstarsys.com>
>> *Responder a: *"dev@httpd.apache.org" <dev@httpd.apache.org>
>> *Fecha: *jueves, 26 de enero de 2023, 5:17
>> *Para: *"dev@httpd.apache.org" <dev@httpd.apache.org>
>> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>>
>>
>>
>> Still, the idea is wicked cool if mod_wasm really can isolate the Python,
>> PHP, etc targets onto individual POSIX threads.
>>
>>
>>
>> Very exciting stuff for HTTP/2 Webapps.
>>
>

Thanks Joe for your encouragement! And yes, your feedback was what inspired us to expand mod_wasm in this direction.

In the demo from my colleague Asen, we expose three wrapper functions to WebAssembly get_header, set_header, delete_header, that internally make use of apr_table_get, apr_table_set and apr_table_unset with the incoming request headers (r->headers_in). This shows read and write capabilities from a Wasm binary using internal Apache APIs. Is this what you are referring to with exposing apreq_*?

Limiting to read-only (ie: just get_header) implies that some functionality that is possible with other extension modules (mod_headers, mod_perl, mod_lua, etc.) won’t be available in mod_wasm. We would love to know more about those concerns, so we can understand better how to develop mod_wasm in a way that both allows you to develop fully capable modules but still address any concerns you may have.

BTW, here is a recent article showing how mod_wasm can help mitigating vulnerabilities https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/, proving how it adds an extra layer of security to traditional applications.

Looking forward to your feedback.

De: Joe Schaefer <joe@sunstarsys.com>
Fecha: jueves, 1 de junio de 2023, 22:16
Para: dev@httpd.apache.org <dev@httpd.apache.org>
Asunto: Re: mod_wasm: Contributing Upstream to Apache
!! External Email
Huge fan, love that you are receptive to my feedback. If you get to the point where the apreq_* (APR table-based) interfaces in trunk can be exposed as read-only data structures in mod_wasm as an optional API for power httpd users that like the sandboxed functionality you get OOTB, that would justify a lot of the more conservative concerns that some devs have for not putting incorporating this into the trunk codebase, which would be my recommendation at that point for how to get it into a releasable tree at some point.


On Tue, May 30, 2023 at 8:42?AM José Carlos Chávez <jcchavezs@apache.org<mailto:jcchavezs@apache.org>> wrote:
I think not making WASM a first class concern in a proxy or server is missing out, more so in those platforms where extensibility isn't trivial. Apache will remain running in current setups but having limited extensibility is something concerning these days as systems are getting more and more complex. Writing an apache module isn't something you do every day and it probably takes quite some time, writing a wasm app following certain ABI is something you can do in minutes, hence supporting mod_wasm as a first class concern could be a good point in the sustainability of an ecosystem when it comes to moving forward out of the status quo.

On 2022/11/14 06:37:34 Jesús González wrote:
> Hi everyone,
>
>
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<http://wasmlabs.dev/><https://wasmlabs.dev/>, a group focused on creating open source tools for WebAssembly.
>
> We have created mod_wasm, an Apache module for running WebAssembly binaries inside httpd, and we would like to contribute it upstream. Please see below for more details. We would love to get your feedback and understand what improvements would be needed (if any) before it could be considered for contribution to the project.
>
>
>
>
>
> The details:
>
>
>
> WebAssembly<https://webassembly.org/> (Wasm) is a new binary instruction format that is open, portable, efficient, secure, and polyglot. It originated in the browser but is increasingly used in server applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/).
>
>
>
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is similar to how mod_php embeds a PHP runtime to run PHP code. This enables any language that supports WebAssembly (including C++, Rust, Go but also Python, PHP, Ruby) to run with mod_wasm and take advantage of the extra level of security and sandboxing. To learn more about mod_wasm you can check out the following resources:
>
> * An overview article<https://wasmlabs.dev/articles/apache-mod-wasm/> for the original release.
> * We presented mod_wasm at ApacheCon this year and here are the slides<https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf<https://apachecon.com/acna2022/slides/01_Gonz%C3%A1lez_mod-wasm_Bringing_WebAssembly.pdf>> and the source code: https://github.com/vmware-labs/mod_wasm.
> * CNCF Talk on mod_wasm showcasing how to run WordPress: https://www.youtube.com/watch?v=jXe8kulUscQ
>
>
>
> In terms of mod_wasm architecture, the module is split into two parts:
>
> * mod_wasm.so is the extension module for Apache and it’s written in C.
> * An external dependency: libwasm_runtime.so, which is written in Rust and needs to be installed into the system.
>
>
>
> We modelled this after mod_tls, a module that is part of httpd and also has a Rust dependency.
>
> You can take a look at the architecture diagram and instructions on how to build the module here: https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
>
>
>
> In terms of the actual contribution, please find a patch attached. We tried to follow all existing conventions in terms of autoconf/automake, providing module documentation, etc. Please let us know anything that you see missing or could be improved. In particular, we do not know yet if it is better to keep the Rust code separate, as an external dependency (like mod_tls does) or in the Apache source code repository.
>
>
>
> In summary, we believe mod_wasm is a worthy addition to httpd and it will allow us to catch up to some of the other web servers already supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim Jagielski and Jean-Frederic Clere to submit it for contribution upstream and we are looking forward to your feedback.
>
>
>
> Cheers!
>
> Jesús
>
>
>
>
>

!! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.

Hola!

mod_wasm v0.12.1<https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> is now available!

This maintenance release bumps Wasmtime to 10.0.1, including preliminary support for WASI preview 2 among other improvements and fixes.

Best,
Jesús

De: Jesús González <jesusgm@vmware.com>
Fecha: viernes, 2 de junio de 2023, 19:09
Para: dev@httpd.apache.org <dev@httpd.apache.org>
Asunto: Re: mod_wasm: Contributing Upstream to Apache
Thanks Joe for your encouragement! And yes, your feedback was what inspired us to expand mod_wasm in this direction.

In the demo from my colleague Asen, we expose three wrapper functions to WebAssembly get_header, set_header, delete_header, that internally make use of apr_table_get, apr_table_set and apr_table_unset with the incoming request headers (r->headers_in). This shows read and write capabilities from a Wasm binary using internal Apache APIs. Is this what you are referring to with exposing apreq_*?

Limiting to read-only (ie: just get_header) implies that some functionality that is possible with other extension modules (mod_headers, mod_perl, mod_lua, etc.) won’t be available in mod_wasm. We would love to know more about those concerns, so we can understand better how to develop mod_wasm in a way that both allows you to develop fully capable modules but still address any concerns you may have.

BTW, here is a recent article showing how mod_wasm can help mitigating vulnerabilities https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/, proving how it adds an extra layer of security to traditional applications.

Looking forward to your feedback.


De: Joe Schaefer <joe@sunstarsys.com>
Fecha: jueves, 1 de junio de 2023, 22:16
Para: dev@httpd.apache.org <dev@httpd.apache.org>
Asunto: Re: mod_wasm: Contributing Upstream to Apache
!! External Email
Huge fan, love that you are receptive to my feedback. If you get to the point where the apreq_* (APR table-based) interfaces in trunk can be exposed as read-only data structures in mod_wasm as an optional API for power httpd users that like the sandboxed functionality you get OOTB, that would justify a lot of the more conservative concerns that some devs have for not putting incorporating this into the trunk codebase, which would be my recommendation at that point for how to get it into a releasable tree at some point.


On Tue, May 30, 2023 at 8:42?AM José Carlos Chávez <jcchavezs@apache.org<mailto:jcchavezs@apache.org>> wrote:
I think not making WASM a first class concern in a proxy or server is missing out, more so in those platforms where extensibility isn't trivial. Apache will remain running in current setups but having limited extensibility is something concerning these days as systems are getting more and more complex. Writing an apache module isn't something you do every day and it probably takes quite some time, writing a wasm app following certain ABI is something you can do in minutes, hence supporting mod_wasm as a first class concern could be a good point in the sustainability of an ecosystem when it comes to moving forward out of the status quo.

On 2022/11/14 06:37:34 Jesús González wrote:
> Hi everyone,
>
>
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<http://wasmlabs.dev/><https://wasmlabs.dev/>, a group focused on creating open source tools for WebAssembly.
>
> We have created mod_wasm, an Apache module for running WebAssembly binaries inside httpd, and we would like to contribute it upstream. Please see below for more details. We would love to get your feedback and understand what improvements would be needed (if any) before it could be considered for contribution to the project.
>
>
>
>
>
> The details:
>
>
>
> WebAssembly<https://webassembly.org/> (Wasm) is a new binary instruction format that is open, portable, efficient, secure, and polyglot. It originated in the browser but is increasingly used in server applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/).
>
>
>
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is similar to how mod_php embeds a PHP runtime to run PHP code. This enables any language that supports WebAssembly (including C++, Rust, Go but also Python, PHP, Ruby) to run with mod_wasm and take advantage of the extra level of security and sandboxing. To learn more about mod_wasm you can check out the following resources:
>
> * An overview article<https://wasmlabs.dev/articles/apache-mod-wasm/> for the original release.
> * We presented mod_wasm at ApacheCon this year and here are the slides<https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf<https://apachecon.com/acna2022/slides/01_Gonz%C3%A1lez_mod-wasm_Bringing_WebAssembly.pdf>> and the source code: https://github.com/vmware-labs/mod_wasm.
> * CNCF Talk on mod_wasm showcasing how to run WordPress: https://www.youtube.com/watch?v=jXe8kulUscQ
>
>
>
> In terms of mod_wasm architecture, the module is split into two parts:
>
> * mod_wasm.so is the extension module for Apache and it’s written in C.
> * An external dependency: libwasm_runtime.so, which is written in Rust and needs to be installed into the system.
>
>
>
> We modelled this after mod_tls, a module that is part of httpd and also has a Rust dependency.
>
> You can take a look at the architecture diagram and instructions on how to build the module here: https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
>
>
>
> In terms of the actual contribution, please find a patch attached. We tried to follow all existing conventions in terms of autoconf/automake, providing module documentation, etc. Please let us know anything that you see missing or could be improved. In particular, we do not know yet if it is better to keep the Rust code separate, as an external dependency (like mod_tls does) or in the Apache source code repository.
>
>
>
> In summary, we believe mod_wasm is a worthy addition to httpd and it will allow us to catch up to some of the other web servers already supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim Jagielski and Jean-Frederic Clere to submit it for contribution upstream and we are looking forward to your feedback.
>
>
>
> Cheers!
>
> Jesús
>
>
>
>
>

!! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.

The more of the API you expose, the less value the sandbox has to end users. For Webapps, easy read/search / write/ iterate is essential. But also form data; which apreq stores in readonly apr tables.

Joe Schaefer, Ph.D
<joe@sunstarsys.com>
+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki

________________________________
From: Jesús González <jesusgm@vmware.com>
Sent: Monday, July 3, 2023 8:49:33 AM
To: dev@httpd.apache.org <dev@httpd.apache.org>
Subject: Re: mod_wasm: Contributing Upstream to Apache


Hola!

mod_wasm v0.12.1<https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> is now available!

This maintenance release bumps Wasmtime to 10.0.1, including preliminary support for WASI preview 2 among other improvements and fixes.

Best,
Jesús



De: Jesús González <jesusgm@vmware.com>
Fecha: viernes, 2 de junio de 2023, 19:09
Para: dev@httpd.apache.org <dev@httpd.apache.org>
Asunto: Re: mod_wasm: Contributing Upstream to Apache

Thanks Joe for your encouragement! And yes, your feedback was what inspired us to expand mod_wasm in this direction.

In the demo from my colleague Asen, we expose three wrapper functions to WebAssembly get_header, set_header, delete_header, that internally make use of apr_table_get, apr_table_set and apr_table_unset with the incoming request headers (r->headers_in). This shows read and write capabilities from a Wasm binary using internal Apache APIs. Is this what you are referring to with exposing apreq_*?

Limiting to read-only (ie: just get_header) implies that some functionality that is possible with other extension modules (mod_headers, mod_perl, mod_lua, etc.) won’t be available in mod_wasm. We would love to know more about those concerns, so we can understand better how to develop mod_wasm in a way that both allows you to develop fully capable modules but still address any concerns you may have.

BTW, here is a recent article showing how mod_wasm can help mitigating vulnerabilities https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/, proving how it adds an extra layer of security to traditional applications.

Looking forward to your feedback.



De: Joe Schaefer <joe@sunstarsys.com>
Fecha: jueves, 1 de junio de 2023, 22:16
Para: dev@httpd.apache.org <dev@httpd.apache.org>
Asunto: Re: mod_wasm: Contributing Upstream to Apache

!! External Email

Huge fan, love that you are receptive to my feedback. If you get to the point where the apreq_* (APR table-based) interfaces in trunk can be exposed as read-only data structures in mod_wasm as an optional API for power httpd users that like the sandboxed functionality you get OOTB, that would justify a lot of the more conservative concerns that some devs have for not putting incorporating this into the trunk codebase, which would be my recommendation at that point for how to get it into a releasable tree at some point.





On Tue, May 30, 2023 at 8:42?AM José Carlos Chávez <jcchavezs@apache.org<mailto:jcchavezs@apache.org>> wrote:

I think not making WASM a first class concern in a proxy or server is missing out, more so in those platforms where extensibility isn't trivial. Apache will remain running in current setups but having limited extensibility is something concerning these days as systems are getting more and more complex. Writing an apache module isn't something you do every day and it probably takes quite some time, writing a wasm app following certain ABI is something you can do in minutes, hence supporting mod_wasm as a first class concern could be a good point in the sustainability of an ecosystem when it comes to moving forward out of the status quo.

On 2022/11/14 06:37:34 Jesús González wrote:
> Hi everyone,
>
>
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<http://wasmlabs.dev/><https://wasmlabs.dev/>, a group focused on creating open source tools for WebAssembly.
>
> We have created mod_wasm, an Apache module for running WebAssembly binaries inside httpd, and we would like to contribute it upstream. Please see below for more details. We would love to get your feedback and understand what improvements would be needed (if any) before it could be considered for contribution to the project.
>
>
>
>
>
> The details:
>
>
>
> WebAssembly<https://webassembly.org/> (Wasm) is a new binary instruction format that is open, portable, efficient, secure, and polyglot. It originated in the browser but is increasingly used in server applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/).
>
>
>
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is similar to how mod_php embeds a PHP runtime to run PHP code. This enables any language that supports WebAssembly (including C++, Rust, Go but also Python, PHP, Ruby) to run with mod_wasm and take advantage of the extra level of security and sandboxing. To learn more about mod_wasm you can check out the following resources:
>
> * An overview article<https://wasmlabs.dev/articles/apache-mod-wasm/> for the original release.
> * We presented mod_wasm at ApacheCon this year and here are the slides<https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf<https://apachecon.com/acna2022/slides/01_Gonz%C3%A1lez_mod-wasm_Bringing_WebAssembly.pdf>> and the source code: https://github.com/vmware-labs/mod_wasm.
> * CNCF Talk on mod_wasm showcasing how to run WordPress: https://www.youtube.com/watch?v=jXe8kulUscQ
>
>
>
> In terms of mod_wasm architecture, the module is split into two parts:
>
> * mod_wasm.so is the extension module for Apache and it’s written in C.
> * An external dependency: libwasm_runtime.so, which is written in Rust and needs to be installed into the system.
>
>
>
> We modelled this after mod_tls, a module that is part of httpd and also has a Rust dependency.
>
> You can take a look at the architecture diagram and instructions on how to build the module here: https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
>
>
>
> In terms of the actual contribution, please find a patch attached. We tried to follow all existing conventions in terms of autoconf/automake, providing module documentation, etc. Please let us know anything that you see missing or could be improved. In particular, we do not know yet if it is better to keep the Rust code separate, as an external dependency (like mod_tls does) or in the Apache source code repository.
>
>
>
> In summary, we believe mod_wasm is a worthy addition to httpd and it will allow us to catch up to some of the other web servers already supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim Jagielski and Jean-Frederic Clere to submit it for contribution upstream and we are looking forward to your feedback.
>
>
>
> Cheers!
>
> Jesús
>
>
>
>
>



!! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.

The win with having an apr table api from httpd is that by sharing those
tables in the sandbox, various programming languages will be able to
interact with others without stealing the client form inputs.

Even if you don’t go that route, and just expose the form inputs on stdin
in your app, users can always configure apreq’s input filter to activate on
the protocol filter chain before wasm activates. That way other modules
still can access form input without breaking the Wasm app.

On Tue, Jul 4, 2023 at 10:48 PM Joe Schaefer <joe@sunstarsys.com> wrote:

> The more of the API you expose, the less value the sandbox has to end
> users. For Webapps, easy read/search / write/ iterate is essential. But
> also form data; which apreq stores in readonly apr tables.
>
> Joe Schaefer, Ph.D
> <joe@sunstarsys.com>
> +1 (954) 253-3732
> SunStar Systems, Inc.
> *Orion - The Enterprise Jamstack Wiki*
>
> ------------------------------
> *From:* Jesús González <jesusgm@vmware.com>
> *Sent:* Monday, July 3, 2023 8:49:33 AM
> *To:* dev@httpd.apache.org <dev@httpd.apache.org>
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
>
> Hola!
>
> mod_wasm v0.12.1
> <https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> is now
> available!
>
> This maintenance release bumps Wasmtime to 10.0.1, including preliminary
> support for WASI preview 2 among other improvements and fixes.
>
> Best,
> Jesús
>
>
>
> *De: *Jesús González <jesusgm@vmware.com>
> *Fecha: *viernes, 2 de junio de 2023, 19:09
> *Para: *dev@httpd.apache.org <dev@httpd.apache.org>
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> Thanks Joe for your encouragement! And yes, your feedback was what
> inspired us to expand mod_wasm in this direction.
>
> In the demo from my colleague Asen, we expose three wrapper functions to
> WebAssembly get_header, set_header, delete_header, that internally make use
> of apr_table_get, apr_table_set and apr_table_unset with the incoming
> request headers (r->headers_in). This shows read and write capabilities
> from a Wasm binary using internal Apache APIs. Is this what you are
> referring to with exposing apreq_*?
>
> Limiting to read-only (ie: just get_header) implies that some
> functionality that is possible with other extension modules (mod_headers,
> mod_perl, mod_lua, etc.) won’t be available in mod_wasm. We would love to
> know more about those concerns, so we can understand better how to develop
> mod_wasm in a way that both allows you to develop fully capable modules but
> still address any concerns you may have.
>
> BTW, here is a recent article showing how mod_wasm can help mitigating
> vulnerabilities
> https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/,
> proving how it adds an extra layer of security to traditional applications.
>
> Looking forward to your feedback.
>
>
> *De: *Joe Schaefer <joe@sunstarsys.com>
> *Fecha: *jueves, 1 de junio de 2023, 22:16
> *Para: *dev@httpd.apache.org <dev@httpd.apache.org>
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> *!! External Email*
>
> Huge fan, love that you are receptive to my feedback. If you get to the
> point where the apreq_* (APR table-based) interfaces in trunk can be
> exposed as read-only data structures in mod_wasm as an optional API for
> power httpd users that like the sandboxed functionality you get OOTB, that
> would justify a lot of the more conservative concerns that some devs have
> for not putting incorporating this into the trunk codebase, which would be
> my recommendation at that point for how to get it into a releasable tree at
> some point.
>
>
>
>
>
> On Tue, May 30, 2023 at 8:42?AM José Carlos Chávez <jcchavezs@apache.org>
> wrote:
>
> I think not making WASM a first class concern in a proxy or server is
> missing out, more so in those platforms where extensibility isn't trivial.
> Apache will remain running in current setups but having limited
> extensibility is something concerning these days as systems are getting
> more and more complex. Writing an apache module isn't something you do
> every day and it probably takes quite some time, writing a wasm app
> following certain ABI is something you can do in minutes, hence supporting
> mod_wasm as a first class concern could be a good point in the
> sustainability of an ecosystem when it comes to moving forward out of the
> status quo.
>
> On 2022/11/14 06:37:34 Jesús González wrote:
> > Hi everyone,
> >
> >
> >
> > I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<
> https://wasmlabs.dev/>, a group focused on creating open source tools for
> WebAssembly.
> >
> > We have created mod_wasm, an Apache module for running WebAssembly
> binaries inside httpd, and we would like to contribute it upstream. Please
> see below for more details. We would love to get your feedback and
> understand what improvements would be needed (if any) before it could be
> considered for contribution to the project.
> >
> >
> >
> >
> >
> > The details:
> >
> >
> >
> > WebAssembly<https://webassembly.org/> (Wasm) is a new binary
> instruction format that is open, portable, efficient, secure, and polyglot.
> It originated in the browser but is increasingly used in server
> applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based
> plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/).
> >
> >
> >
> > mod_wasm is a way to run WebAssembly modules inside Apache Server. This
> is similar to how mod_php embeds a PHP runtime to run PHP code. This
> enables any language that supports WebAssembly (including C++, Rust, Go but
> also Python, PHP, Ruby) to run with mod_wasm and take advantage of the
> extra level of security and sandboxing. To learn more about mod_wasm you
> can check out the following resources:
> >
> > * An overview article<https://wasmlabs.dev/articles/apache-mod-wasm/>
> for the original release.
> > * We presented mod_wasm at ApacheCon this year and here are the
> slides<
> https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf
> <https://apachecon.com/acna2022/slides/01_Gonz%C3%A1lez_mod-wasm_Bringing_WebAssembly.pdf>>
> and the source code: https://github.com/vmware-labs/mod_wasm.
> > * CNCF Talk on mod_wasm showcasing how to run WordPress:
> https://www.youtube.com/watch?v=jXe8kulUscQ
> >
> >
> >
> > In terms of mod_wasm architecture, the module is split into two parts:
> >
> > * mod_wasm.so is the extension module for Apache and it’s written in
> C.
> > * An external dependency: libwasm_runtime.so, which is written in
> Rust and needs to be installed into the system.
> >
> >
> >
> > We modelled this after mod_tls, a module that is part of httpd and also
> has a Rust dependency.
> >
> > You can take a look at the architecture diagram and instructions on how
> to build the module here:
> https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
> >
> >
> >
> > In terms of the actual contribution, please find a patch attached. We
> tried to follow all existing conventions in terms of autoconf/automake,
> providing module documentation, etc. Please let us know anything that you
> see missing or could be improved. In particular, we do not know yet if it
> is better to keep the Rust code separate, as an external dependency (like
> mod_tls does) or in the Apache source code repository.
> >
> >
> >
> > In summary, we believe mod_wasm is a worthy addition to httpd and it
> will allow us to catch up to some of the other web servers already
> supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim
> Jagielski and Jean-Frederic Clere to submit it for contribution upstream
> and we are looking forward to your feedback.
> >
> >
> >
> > Cheers!
> >
> > Jesús
> >
> >
> >
> >
> >
>
>
>
> *!! External Email:* This email originated from outside of the
> organization. Do not click links or open attachments unless you recognize
> the sender.
>
>
>
--
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

Joe, thanks for your feedback!

Just to make sure I understand this feedback, what you are mentioning is that exposing the internals of Apache diminishes the value of the sandbox because programs could potentially perform write operations into the internals of httpd state, tables, etc. Is that correct?

If my understanding is correct, this should not be an issue:

- The current incarnation of mod_wasm is implemented as a content-handler and does not have access to the internals of Apache or tables. All the information is passed through environment variables, similar to a traditional CGI binary, but running in the Wasm sandbox (so you can control tightly any access to filesystem, network, etc.).

- The proposed changes to mod_wasm that enable writing Apache modules in other languages would expose the API, but that’s the idea: to make it easy to build fully featured Apache modules using any language that can compile to Wasm (ie: Go, Python). Think of this as an ‘universal’ polyglot version of mod_lua with added sandboxing capabilities.

Which mode to use can be configured. You definitely don’t want random users having access to the internals of httpd when serving their regular application (ie: Drupal).

Having said all of this, regarding the read-only structs, a Wasm binary cannot access the host memory space. So, a pointer to an apr table in the httpd memory space cannot be dereferenced within the sandbox. There exist opaque reference types (ie: externref) to host objects that comply with WebAssembly sandboxing guarantees as explained in https://fitzgeraldnick.com/2020/08/27/reference-types-in-wasmtime.html. This is great in terms of security, but a drawback from a performance perspective. To manipulate data structs, either they are copied into the Wasm memory and copied back to the server, or we offer a set of limited interfaces to the Wasm binary to perform such actions. So yes, we believe your proposal of getting the apreq_* (ARP table-based) interfaces exposed as read-only data structures is doable and useful.

Cheers!

De: Joe Schaefer <joe@sunstarsys.com>
Fecha: miércoles, 5 de julio de 2023, 4:59
Para: dev@httpd.apache.org <dev@httpd.apache.org>
Asunto: Re: mod_wasm: Contributing Upstream to Apache
!! External Email
The win with having an apr table api from httpd is that by sharing those tables in the sandbox, various programming languages will be able to interact with others without stealing the client form inputs.

Even if you don’t go that route, and just expose the form inputs on stdin in your app, users can always configure apreq’s input filter to activate on the protocol filter chain before wasm activates. That way other modules still can access form input without breaking the Wasm app.

On Tue, Jul 4, 2023 at 10:48 PM Joe Schaefer <joe@sunstarsys.com<mailto:joe@sunstarsys.com>> wrote:
The more of the API you expose, the less value the sandbox has to end users. For Webapps, easy read/search / write/ iterate is essential. But also form data; which apreq stores in readonly apr tables.

Joe Schaefer, Ph.D
<joe@sunstarsys.com<mailto:joe@sunstarsys.com>>
+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki

________________________________
From: Jesús González <jesusgm@vmware.com<mailto:jesusgm@vmware.com>>
Sent: Monday, July 3, 2023 8:49:33 AM
To: dev@httpd.apache.org<mailto:dev@httpd.apache.org> <dev@httpd.apache.org<mailto:dev@httpd.apache.org>>
Subject: Re: mod_wasm: Contributing Upstream to Apache


Hola!

mod_wasm v0.12.1<https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> is now available!

This maintenance release bumps Wasmtime to 10.0.1, including preliminary support for WASI preview 2 among other improvements and fixes.

Best,
Jesús



De: Jesús González <jesusgm@vmware.com<mailto:jesusgm@vmware.com>>
Fecha: viernes, 2 de junio de 2023, 19:09
Para: dev@httpd.apache.org<mailto:dev@httpd.apache.org> <dev@httpd.apache.org<mailto:dev@httpd.apache.org>>
Asunto: Re: mod_wasm: Contributing Upstream to Apache

Thanks Joe for your encouragement! And yes, your feedback was what inspired us to expand mod_wasm in this direction.

In the demo from my colleague Asen, we expose three wrapper functions to WebAssembly get_header, set_header, delete_header, that internally make use of apr_table_get, apr_table_set and apr_table_unset with the incoming request headers (r->headers_in). This shows read and write capabilities from a Wasm binary using internal Apache APIs. Is this what you are referring to with exposing apreq_*?

Limiting to read-only (ie: just get_header) implies that some functionality that is possible with other extension modules (mod_headers, mod_perl, mod_lua, etc.) won’t be available in mod_wasm. We would love to know more about those concerns, so we can understand better how to develop mod_wasm in a way that both allows you to develop fully capable modules but still address any concerns you may have.

BTW, here is a recent article showing how mod_wasm can help mitigating vulnerabilities https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/, proving how it adds an extra layer of security to traditional applications.

Looking forward to your feedback.


De: Joe Schaefer <joe@sunstarsys.com<mailto:joe@sunstarsys.com>>
Fecha: jueves, 1 de junio de 2023, 22:16
Para: dev@httpd.apache.org<mailto:dev@httpd.apache.org> <dev@httpd.apache.org<mailto:dev@httpd.apache.org>>
Asunto: Re: mod_wasm: Contributing Upstream to Apache

!! External Email

Huge fan, love that you are receptive to my feedback. If you get to the point where the apreq_* (APR table-based) interfaces in trunk can be exposed as read-only data structures in mod_wasm as an optional API for power httpd users that like the sandboxed functionality you get OOTB, that would justify a lot of the more conservative concerns that some devs have for not putting incorporating this into the trunk codebase, which would be my recommendation at that point for how to get it into a releasable tree at some point.





On Tue, May 30, 2023 at 8:42?AM José Carlos Chávez <jcchavezs@apache.org<mailto:jcchavezs@apache.org>> wrote:

I think not making WASM a first class concern in a proxy or server is missing out, more so in those platforms where extensibility isn't trivial. Apache will remain running in current setups but having limited extensibility is something concerning these days as systems are getting more and more complex. Writing an apache module isn't something you do every day and it probably takes quite some time, writing a wasm app following certain ABI is something you can do in minutes, hence supporting mod_wasm as a first class concern could be a good point in the sustainability of an ecosystem when it comes to moving forward out of the status quo.

On 2022/11/14 06:37:34 Jesús González wrote:
> Hi everyone,
>
>
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<http://wasmlabs.dev/><https://wasmlabs.dev/>, a group focused on creating open source tools for WebAssembly.
>
> We have created mod_wasm, an Apache module for running WebAssembly binaries inside httpd, and we would like to contribute it upstream. Please see below for more details. We would love to get your feedback and understand what improvements would be needed (if any) before it could be considered for contribution to the project.
>
>
>
>
>
> The details:
>
>
>
> WebAssembly<https://webassembly.org/> (Wasm) is a new binary instruction format that is open, portable, efficient, secure, and polyglot. It originated in the browser but is increasingly used in server applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/).
>
>
>
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is similar to how mod_php embeds a PHP runtime to run PHP code. This enables any language that supports WebAssembly (including C++, Rust, Go but also Python, PHP, Ruby) to run with mod_wasm and take advantage of the extra level of security and sandboxing. To learn more about mod_wasm you can check out the following resources:
>
> * An overview article<https://wasmlabs.dev/articles/apache-mod-wasm/> for the original release.
> * We presented mod_wasm at ApacheCon this year and here are the slides<https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf<https://apachecon.com/acna2022/slides/01_Gonz%C3%A1lez_mod-wasm_Bringing_WebAssembly.pdf>> and the source code: https://github.com/vmware-labs/mod_wasm.
> * CNCF Talk on mod_wasm showcasing how to run WordPress: https://www.youtube.com/watch?v=jXe8kulUscQ
>
>
>
> In terms of mod_wasm architecture, the module is split into two parts:
>
> * mod_wasm.so is the extension module for Apache and it’s written in C.
> * An external dependency: libwasm_runtime.so, which is written in Rust and needs to be installed into the system.
>
>
>
> We modelled this after mod_tls, a module that is part of httpd and also has a Rust dependency.
>
> You can take a look at the architecture diagram and instructions on how to build the module here: https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
>
>
>
> In terms of the actual contribution, please find a patch attached. We tried to follow all existing conventions in terms of autoconf/automake, providing module documentation, etc. Please let us know anything that you see missing or could be improved. In particular, we do not know yet if it is better to keep the Rust code separate, as an external dependency (like mod_tls does) or in the Apache source code repository.
>
>
>
> In summary, we believe mod_wasm is a worthy addition to httpd and it will allow us to catch up to some of the other web servers already supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim Jagielski and Jean-Frederic Clere to submit it for contribution upstream and we are looking forward to your feedback.
>
>
>
> Cheers!
>
> Jesús
>
>
>
>
>



!! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.


--
Joe Schaefer, Ph.D.
[Imagen quitada por el remitente.]<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki<https://sunstarsys.com/orion/features>
<joe@sunstarsys.com<mailto:joe@sunstarsys.com>>
954.253.3732<tel://954.253.3732>

All good. Just didn’t want to see needless delays in getting this stuff
incorporated while you build out the non-content handler mode for mod_wasm
that IMO will never be in big demand (if it were, mod_perl wouldn’t be such
a stagnant community over the past two decades).

On Fri, Jul 7, 2023 at 4:07 PM Jesús González <jesusgm@vmware.com> wrote:

> Joe, thanks for your feedback!
>
>
>
> Just to make sure I understand this feedback, what you are mentioning is
> that exposing the internals of Apache diminishes the value of the sandbox
> because programs could potentially perform write operations into the
> internals of httpd state, tables, etc. Is that correct?
>
>
>
> If my understanding is correct, this should not be an issue:
>
>
>
> - The current incarnation of mod_wasm is implemented as a content-handler
> and does not have access to the internals of Apache or tables. All the
> information is passed through environment variables, similar to a
> traditional CGI binary, but running in the Wasm sandbox (so you can control
> tightly any access to filesystem, network, etc.).
>
>
>
> - The proposed changes to mod_wasm that enable writing Apache modules in
> other languages would expose the API, but that’s the idea: to make it easy
> to build fully featured Apache modules using any language that can compile
> to Wasm (ie: Go, Python). Think of this as an ‘universal’ polyglot version
> of mod_lua with added sandboxing capabilities.
>
>
>
> Which mode to use can be configured. You definitely don’t want random
> users having access to the internals of httpd when serving their regular
> application (ie: Drupal).
>
>
>
> Having said all of this, regarding the read-only structs, a Wasm binary
> cannot access the host memory space. So, a pointer to an apr table in the
> httpd memory space cannot be dereferenced within the sandbox. There exist
> opaque reference types (ie: externref) to host objects that comply with
> WebAssembly sandboxing guarantees as explained in
> https://fitzgeraldnick.com/2020/08/27/reference-types-in-wasmtime.html.
> This is great in terms of security, but a drawback from a performance
> perspective. To manipulate data structs, either they are copied into the
> Wasm memory and copied back to the server, or we offer a set of limited
> interfaces to the Wasm binary to perform such actions. So yes, we believe
> your proposal of getting the apreq_* (ARP table-based) interfaces exposed
> as read-only data structures is doable and useful.
>
> Cheers!
>
>
>
> *De: *Joe Schaefer <joe@sunstarsys.com>
> *Fecha: *miércoles, 5 de julio de 2023, 4:59
> *Para: *dev@httpd.apache.org <dev@httpd.apache.org>
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> *!! External Email*
>
> The win with having an apr table api from httpd is that by sharing those
> tables in the sandbox, various programming languages will be able to
> interact with others without stealing the client form inputs.
>
>
>
> Even if you don’t go that route, and just expose the form inputs on stdin
> in your app, users can always configure apreq’s input filter to activate on
> the protocol filter chain before wasm activates. That way other modules
> still can access form input without breaking the Wasm app.
>
>
>
> On Tue, Jul 4, 2023 at 10:48 PM Joe Schaefer <joe@sunstarsys.com> wrote:
>
> The more of the API you expose, the less value the sandbox has to end
> users. For Webapps, easy read/search / write/ iterate is essential. But
> also form data; which apreq stores in readonly apr tables.
>
>
>
> Joe Schaefer, Ph.D
>
> <joe@sunstarsys.com>
>
> +1 (954) 253-3732
>
> SunStar Systems, Inc.
>
> *Orion - The Enterprise Jamstack Wiki*
>
>
> ------------------------------
>
> *From:* Jesús González <jesusgm@vmware.com>
> *Sent:* Monday, July 3, 2023 8:49:33 AM
> *To:* dev@httpd.apache.org <dev@httpd.apache.org>
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
>
>
> Hola!
>
> mod_wasm v0.12.1
> <https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> is now
> available!
>
> This maintenance release bumps Wasmtime to 10.0.1, including preliminary
> support for WASI preview 2 among other improvements and fixes.
>
> Best,
> Jesús
>
>
>
> *De: *Jesús González <jesusgm@vmware.com>
> *Fecha: *viernes, 2 de junio de 2023, 19:09
> *Para: *dev@httpd.apache.org <dev@httpd.apache.org>
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> Thanks Joe for your encouragement! And yes, your feedback was what
> inspired us to expand mod_wasm in this direction.
>
> In the demo from my colleague Asen, we expose three wrapper functions to
> WebAssembly get_header, set_header, delete_header, that internally make use
> of apr_table_get, apr_table_set and apr_table_unset with the incoming
> request headers (r->headers_in). This shows read and write capabilities
> from a Wasm binary using internal Apache APIs. Is this what you are
> referring to with exposing apreq_*?
>
> Limiting to read-only (ie: just get_header) implies that some
> functionality that is possible with other extension modules (mod_headers,
> mod_perl, mod_lua, etc.) won’t be available in mod_wasm. We would love to
> know more about those concerns, so we can understand better how to develop
> mod_wasm in a way that both allows you to develop fully capable modules but
> still address any concerns you may have.
>
> BTW, here is a recent article showing how mod_wasm can help mitigating
> vulnerabilities
> https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/,
> proving how it adds an extra layer of security to traditional applications.
>
> Looking forward to your feedback.
>
> *De: *Joe Schaefer <joe@sunstarsys.com>
> *Fecha: *jueves, 1 de junio de 2023, 22:16
> *Para: *dev@httpd.apache.org <dev@httpd.apache.org>
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> *!! External Email*
>
> Huge fan, love that you are receptive to my feedback. If you get to the
> point where the apreq_* (APR table-based) interfaces in trunk can be
> exposed as read-only data structures in mod_wasm as an optional API for
> power httpd users that like the sandboxed functionality you get OOTB, that
> would justify a lot of the more conservative concerns that some devs have
> for not putting incorporating this into the trunk codebase, which would be
> my recommendation at that point for how to get it into a releasable tree at
> some point.
>
>
>
>
>
> On Tue, May 30, 2023 at 8:42?AM José Carlos Chávez <jcchavezs@apache.org>
> wrote:
>
> I think not making WASM a first class concern in a proxy or server is
> missing out, more so in those platforms where extensibility isn't trivial.
> Apache will remain running in current setups but having limited
> extensibility is something concerning these days as systems are getting
> more and more complex. Writing an apache module isn't something you do
> every day and it probably takes quite some time, writing a wasm app
> following certain ABI is something you can do in minutes, hence supporting
> mod_wasm as a first class concern could be a good point in the
> sustainability of an ecosystem when it comes to moving forward out of the
> status quo.
>
> On 2022/11/14 06:37:34 Jesús González wrote:
> > Hi everyone,
> >
> >
> >
> > I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<
> https://wasmlabs.dev/>, a group focused on creating open source tools for
> WebAssembly.
> >
> > We have created mod_wasm, an Apache module for running WebAssembly
> binaries inside httpd, and we would like to contribute it upstream. Please
> see below for more details. We would love to get your feedback and
> understand what improvements would be needed (if any) before it could be
> considered for contribution to the project.
> >
> >
> >
> >
> >
> > The details:
> >
> >
> >
> > WebAssembly<https://webassembly.org/> (Wasm) is a new binary
> instruction format that is open, portable, efficient, secure, and polyglot.
> It originated in the browser but is increasingly used in server
> applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based
> plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/).
> >
> >
> >
> > mod_wasm is a way to run WebAssembly modules inside Apache Server. This
> is similar to how mod_php embeds a PHP runtime to run PHP code. This
> enables any language that supports WebAssembly (including C++, Rust, Go but
> also Python, PHP, Ruby) to run with mod_wasm and take advantage of the
> extra level of security and sandboxing. To learn more about mod_wasm you
> can check out the following resources:
> >
> > * An overview article<https://wasmlabs.dev/articles/apache-mod-wasm/>
> for the original release.
> > * We presented mod_wasm at ApacheCon this year and here are the
> slides<
> https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf
> <https://apachecon.com/acna2022/slides/01_Gonz%C3%A1lez_mod-wasm_Bringing_WebAssembly.pdf>>
> and the source code: https://github.com/vmware-labs/mod_wasm.
> > * CNCF Talk on mod_wasm showcasing how to run WordPress:
> https://www.youtube.com/watch?v=jXe8kulUscQ
> >
> >
> >
> > In terms of mod_wasm architecture, the module is split into two parts:
> >
> > * mod_wasm.so is the extension module for Apache and it’s written in
> C.
> > * An external dependency: libwasm_runtime.so, which is written in
> Rust and needs to be installed into the system.
> >
> >
> >
> > We modelled this after mod_tls, a module that is part of httpd and also
> has a Rust dependency.
> >
> > You can take a look at the architecture diagram and instructions on how
> to build the module here:
> https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
> >
> >
> >
> > In terms of the actual contribution, please find a patch attached. We
> tried to follow all existing conventions in terms of autoconf/automake,
> providing module documentation, etc. Please let us know anything that you
> see missing or could be improved. In particular, we do not know yet if it
> is better to keep the Rust code separate, as an external dependency (like
> mod_tls does) or in the Apache source code repository.
> >
> >
> >
> > In summary, we believe mod_wasm is a worthy addition to httpd and it
> will allow us to catch up to some of the other web servers already
> supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim
> Jagielski and Jean-Frederic Clere to submit it for contribution upstream
> and we are looking forward to your feedback.
> >
> >
> >
> > Cheers!
> >
> > Jesús
> >
> >
> >
> >
> >
>
>
>
> *!! External Email:* This email originated from outside of the
> organization. Do not click links or open attachments unless you recognize
> the sender.
>
>
>
> --
>
> Joe Schaefer, Ph.D.
>
> [image: Imagen quitada por el remitente.]
> <https://sunstarsys.com/orion/features>
>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
>
> <joe@sunstarsys.com>
>
> 954.253.3732 <//954.253.3732>
>
>
>
>
>
--
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>