Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQLite builds for WASI since 3.41.0

wasmlabs.dev

Post reply on HN
Print view View original

31–40 of 49 posts

Re: SQLite builds for WASI since 3.41.0

#31

Post by jraph »

foota wrote: post #22
jraph wrote: post #12

Earlier quoted context omitted.

It's not enough to guarantee the code has not been copied from somewhere / can be released in the public domain. The only way to have this guarantee is to write it yourself.

I suppose that's true, but that's no different from any other project, no? If I write a contribution to React that wasn't actually mine, it doesn't matter that it's just open source and not being released into the public domain, it's still a violation of the real author's copyright. So if they've chosen a different risk model than essentially every other company doing open source software then that's up to them, but…

> I'm not sure the need for it follows from it being public domain?

There's something specific about the public domain that in many places, you can't just decide to release something in the public domain. I guess that's why they actually accept contribution but require an affidavit dedicating the contribution into the public domain. IIUC an affidavit specifically needs to be witnessed by taker of oaths, which probably ensures that the work can indeed be put in public domain.

Not sure it's the whole story, or even the main reason, or the correct analyze, though.

Re: SQLite builds for WASI since 3.41.0

#32

Post by candiodari »

i2cmaster wrote: post #25
angelmm wrote: post #23

Earlier quoted context omitted.

(Wasm Labs team member here) SQLite is a pretty popular database and it's a critical dependency for many different applications. By compiling it to Wasm32-wasi, you can add it to any WebAssembly module. This enables a new set of possibilities for Wasm and SQLite. For example, now you can run a full WordPress application in the browser [1][2] / server [3] using the same Wasm module. Note that for the browser these pro…

I guess that's one way to prevent malicious plugins from destroying your site.

It does what WASM is meant to do: it allows extra functionality, such as a database, without exposing more surface area for exploits.

Re: SQLite builds for WASI since 3.41.0

#33

Post by aargh_aargh »

angelmm wrote: post #24
aargh_aargh wrote: post #16

Earlier quoted context omitted.

What I don't get specifically is what's being implemented here with SQLite. Assuming WASI is an interface an application can call into for things like filesystem access, sockets, does this add SQLite as interface (analogously to sqlite.h) next to these as part of WASI? So SQLite will be "under" the interface, i.e. part of a standard runtime? How much "batteries included" is this runtime (planned to be)? If I understo…

The main work behind this patch is to ensure that SQLite can compile to Wasm32-wasi. WASI doesn't offer all syscalls that SQLite may require, so it may require some conditional definitions and code to ensure it works properly. It doesn't mean that SQLite is part of WASI, but you can embed SQLite in a Wasm32-wasi module. In the future, the WASI standard will include more and more features. This will allow SQLite to en…

Ah, so it's SQLite running on top of WASI, as a user (application, or rather library). Thanks for clearing that up for me.

Re: SQLite builds for WASI since 3.41.0

#34

Post by sgbeal »

samwillis wrote: post #6
aargh_aargh wrote: post #2

What would you use this for? I don't get the whole picture and the article doesn't talk about it.

So far the official WASM support from the SQLite project have only targeted WASM in the browser with a JS API. If I follow correctly this is about working with the SQLite team to upstream WASI support, which will eventually enable official support for it, and hence WASM on the server/cloud/edge and other WASI complement runners.

> If I follow correctly this is about working with the SQLite team to upstream WASI support, which will eventually enable official support for it, and hence WASM on the server/cloud/edge and other WASI complement runners.

(sqlite team's Wasm/JS guy here)

That's the long and the short if it. We currently _actively_ target browsers only because our team has exceedingly limited bandwidth and has to be choosy with regards to where our dev time goes. Long-term, we intend to target all wasm platforms, but getting there is an ongoing process.

Re: SQLite builds for WASI since 3.41.0

#35

Post by angelmm »

aargh_aargh wrote: post #33
angelmm wrote: post #24

Earlier quoted context omitted.

The main work behind this patch is to ensure that SQLite can compile to Wasm32-wasi. WASI doesn't offer all syscalls that SQLite may require, so it may require some conditional definitions and code to ensure it works properly. It doesn't mean that SQLite is part of WASI, but you can embed SQLite in a Wasm32-wasi module. In the future, the WASI standard will include more and more features. This will allow SQLite to en…

Ah, so it's SQLite running on top of WASI, as a user (application, or rather library). Thanks for clearing that up for me.

Exactly! :D

Re: SQLite builds for WASI since 3.41.0

#36

Post by rapnie »

fastball wrote: post #11
aargh_aargh wrote: post #2

What would you use this for? I don't get the whole picture and the article doesn't talk about it.

The goal of WASI is to add a standardized system API to WebAssembly, allowing you to access underlying systems (filesystem, networking, etc) in a homomorphic and secure way. In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in…

> homomorphic and secure way

A lot of the sandboxing and security focus in Wasm makes sense. But the "capability-based security" mentioned at WASI spec [0] confuses me. For instance, when looking to what Cosmonic (an early adopter in Wasm fields) documents as capabilities [1] (e.g. 'messaging', 'http client', 'key-value store') it seems wholly different to concepts from the E programming language [2] by Mark S. Miller, that are finding their way in Cap'n Proto [3] and early work on the OCapN [4] unification effort. Is there any relationship to these, or are we looking at totally different approaches? Or is Cosmonic overloading the terminology of "capability"?

[0] https://github.com/WebAssembly/WASI#capability-based-securit...

[1] https://cosmonic.com/docs/category/capabilities

[2] https://en.wikipedia.org/wiki/E_(programming_language)

[3] https://capnproto.org

[4] https://github.com/ocapn/ocapn

Re: SQLite builds for WASI since 3.41.0

#37

Post by sgbeal »

jraph wrote: post #12
foota wrote: post #9

Earlier quoted context omitted.

Looks like this: https://www.sqlite.org/copyright.html Kind of weird, couldn't they use a CLA?

It's not enough to guarantee the code has not been copied from somewhere / can be released in the public domain. The only way to have this guarantee is to write it yourself.

> It's not enough to guarantee the code has not been copied from somewhere / can be released in the public domain.

FWIW, within the sqlite project we have a very strict policy against copy/paste of anything from outside sources. If we don't write it ourselves, it doesn't get added to the canonical source tree, no exceptions.

Re: SQLite builds for WASI since 3.41.0

#38

Post by rapnie »

rapnie wrote: post #36
fastball wrote: post #11

Earlier quoted context omitted.

The goal of WASI is to add a standardized system API to WebAssembly, allowing you to access underlying systems (filesystem, networking, etc) in a homomorphic and secure way. In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in…

> homomorphic and secure way A lot of the sandboxing and security focus in Wasm makes sense. But the "capability-based security" mentioned at WASI spec [0] confuses me. For instance, when looking to what Cosmonic (an early adopter in Wasm fields) documents as capabilities [1] (e.g. 'messaging', 'http client', 'key-value store') it seems wholly different to concepts from the E programming language [2] by Mark S. Mille…

Well, I think it is a different approach. But in another submission I posted, "WebAssembly for the Server Side: A New Way to Nginx" [0], sponsored by Nginx, they mention things feeding the confusion again:

> Perhaps most importantly, role-based access control and attribute-based access control, and other authorization and access control technologies, can introduce complex external systems that must be synchronized with the plugin as well as the underlying server-side technology. In contrast, Wasm access control capabilities are often built directly into the runtime engines, reducing the complexities and simplifying the development process.

[0] https://news.ycombinator.com/item?id=36057066

Re: SQLite builds for WASI since 3.41.0

#39

Post by lioeters »

angelmm wrote: post #23
aargh_aargh wrote: post #2

What would you use this for? I don't get the whole picture and the article doesn't talk about it.

(Wasm Labs team member here) SQLite is a pretty popular database and it's a critical dependency for many different applications. By compiling it to Wasm32-wasi, you can add it to any WebAssembly module. This enables a new set of possibilities for Wasm and SQLite. For example, now you can run a full WordPress application in the browser [1][2] / server [3] using the same Wasm module. Note that for the browser these pro…

> these projects use Emscripten, but in the future the same Wasm32-wasi module will work

I'm curious to know more about this. Does it mean that when browsers support WASI, these projects will not need to use Emscripten? Or maybe use it for compiling to/with WASI but without the need for a runtime anymore.

Is there anywhere I can keep track of when/how this might happen?

Re: SQLite builds for WASI since 3.41.0

#40

Post by kentonv »

rapnie wrote: post #36
fastball wrote: post #11

Earlier quoted context omitted.

The goal of WASI is to add a standardized system API to WebAssembly, allowing you to access underlying systems (filesystem, networking, etc) in a homomorphic and secure way. In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in…

> homomorphic and secure way A lot of the sandboxing and security focus in Wasm makes sense. But the "capability-based security" mentioned at WASI spec [0] confuses me. For instance, when looking to what Cosmonic (an early adopter in Wasm fields) documents as capabilities [1] (e.g. 'messaging', 'http client', 'key-value store') it seems wholly different to concepts from the E programming language [2] by Mark S. Mille…

On a brief look, I agree that your link [1] does not appear to be thinking about capabilities correctly. It seems to make the classic mistake of orienting around verbs (actions you can do) instead of nouns (specific resources you can operate on). That said I only took a brief look and could be misunderstanding something.

However, my understanding is that WASI itself is actually capability-based, and I think your link [0] is thinking about capabilities in the right way. In fact I'm pleased to see "Interposition" seems to have been added here, IIRC a few years ago that was missing and I feel it's an essential piece of capability-based security.

As an example, in WASI, there is no singleton filesystem, instead the application receives a set of file descriptors for specific directories which grant access only to those directories and their children, not their parents. Though last I looked, the libc wanted to reconstruct those into a single virtual filesystem, assigning each one a mount point and matching paths against those, in the name of compatibility, which felt unfortunate to me.

As always, a lot of people struggle to "get" capabilities, even when they are building on top of a platform designed around the idea. :/

Post reply on HN