Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

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  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 
> *Fecha: *miércoles, 5 de julio de 2023, 4:59
> *Para: *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  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
>
> 
>
> +1 (954) 253-3732
>
> SunStar Systems, Inc.
>
> *Orion - The Enterprise Jamstack Wiki*
>
>
> --
>
> *From:* Jesús González 
> *Sent:* Monday, July 3, 2023 8:49:33 AM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
>
>
> Hola!
>
> mod_wasm 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 
> *Fecha: *viernes, 2 de junio de 2023, 19:09
> *Para: *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,

Re: mod_wasm: Contributing Upstream to Apache

[Jesús González]

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 
Fecha: miércoles, 5 de julio de 2023, 4:59
Para: 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 
mailto:j...@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
mailto:j...@sunstarsys.com>>
+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


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


Hola!

mod_wasm 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 mailto:jesu...@vmware.com>>
Fecha: viernes, 2 de junio de 2023, 19:09
Para: 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/,

Re: svn commit: r1910820 - in /httpd/httpd/branches/2.4.x: ./ changes-entries/pr60182.txt modules/ssl/ssl_util_stapling.c

[Joe Orton]

On Thu, Jul 06, 2023 at 10:58:07PM +0200, Christophe JAILLET wrote:
> Le 06/07/2023 à 18:11, jor...@apache.org a écrit :
> > Author: jorton
> > Date: Thu Jul  6 16:11:56 2023
> > New Revision: 1910820
> > 
> > URL: http://svn.apache.org/viewvc?rev=1910820&view=rev
> > Log:
> > Merge r1875355 from trunk:
> > 
> > * modules/ssl/ssl_util_stapling.c (stapling_check_response) Don't stop
> >Certificate Revoked messages.
> > 
> >Certificate Revoked Responder messages don't belong to 'error' class.
> >When the server receives one, it MUST be passed on to the client.
> >And stored for the normal period of basic responses.
> > 
> >Also don't log an error each time it is retrieved from cache,
> >only once when it is retrieved from the OCSP responder.
> > 
> > PR: 60182
> > Obtained from: 
> > https://github.com/apache/httpd/commit/7db9795f45fd4688ceb13ee36090e4e2becbc709.diff
> > Submitted by: 
> > Reviewed by: gbechis, icing, ylavic
> 
> Hi,
> 
> I've not seen it in STATUS.
> 
> I'm a bit distant this days, so I may have missed something, but usually
> STATUS is updated just before or after a commit, and I don't see it either.

Hi Christophe - this was voted for in STATUS under "Fix for BZ 66626" 
though I missed that the bug number mentioned is different to the commit 
message. I've fixed the changes entry just now since 66626 is the right 
one. https://github.com/apache/httpd/blob/2.4.x/STATUS#L196

Thanks for checking & thanks for fixing my typo too.

Regards, Joe