31–40 of 135 posts
I’m interested why Shopify is practically the only sales platform that gets ‘airtime’ at HN.
Is this because partner apps are using Ruby? Does it have something to do with the governance of Shopify? Community of Canadians on HN?
I have some experience with Square, and a few others.
I’m an interested party.
> you cannot express anything malicious in Wasm This feels like a comment that will as age as badly as “you can’t get a virus just from looking at an email”
You can express malicious things in Go, yet the number of RCEs in Go apps is pretty much zero.
Earlier quoted context omitted.
I never said anything was “state of the art” or made any claim that any company is using seccomp to accomplish what Shopify is doing. I said that companies typically run third party native code, e.g. imagemagick, in seccomp to process untrusted data, e.g. user-uploaded image files. If I were tasked with doing what Shopify is doing with wasm here, I would employ the seccomp-based solution since it’s equally applicable…
And i would run wasm with a seccomp profile: You have the benefit of language designed which is hard to not do anything malicious (i guess theres still some possibility) and harden the execution environment (wasm runner) within a rootless pofman/docker container with a seccomp profile and restrictive selinux labels. The world is not black and white, you can mix multiple solutions for more security. For what shopify i…
Imagemagick is not trusted to process arbitrary data, otherwise there would be no need to use seccomp. Seccomp was specifically designed for running untrusted binaries. Check references if you do not believe me: https://en.wikipedia.org/wiki/Seccomp#History
> you cannot express anything malicious in Wasm This feels like a comment that will as age as badly as “you can’t get a virus just from looking at an email”
You can’t express anything malicious in JavaScript either, yet vulnerabilities are constantly found in web browsers, including WebAssembly JITs. You can express malicious things in Go, yet the number of RCEs in Go apps is pretty much zero.
You have to be more specific because lots of fraud is possible by misleading the user through JavaScript tricks.
> you cannot express anything malicious in Wasm This feels like a comment that will as age as badly as “you can’t get a virus just from looking at an email”
You can’t express anything malicious in JavaScript either, yet vulnerabilities are constantly found in web browsers, including WebAssembly JITs. You can express malicious things in Go, yet the number of RCEs in Go apps is pretty much zero.
Earlier quoted context omitted.
They do allow merchants to sell subscriptions - https://help.shopify.com/en/manual/products/subscriptions
I think this is super new - there are only two apps that offer subscriptions that integrate with Shopify Checkout, and one of them launched in November it seems and is still in beta: https://apps.shopify.com/collections/checkout-subscription
Earlier quoted context omitted.
And i would run wasm with a seccomp profile: You have the benefit of language designed which is hard to not do anything malicious (i guess theres still some possibility) and harden the execution environment (wasm runner) within a rootless pofman/docker container with a seccomp profile and restrictive selinux labels. The world is not black and white, you can mix multiple solutions for more security. For what shopify i…
Using wasm in addition to seccomp-bpf (what you’re calling seccomp) strictly increases your attack surface. If you want to maximize security you would only use seccomp. Imagemagick is not trusted to process arbitrary data, otherwise there would be no need to use seccomp. Seccomp was specifically designed for running untrusted binaries. Check references if you do not believe me: https://en.wikipedia.org/wiki/Seccomp#H…
Huh? How so?
Earlier quoted context omitted.
It's not an either/or. Most likely Shopify runs WASM inside an seccomp enclosure. Possibly inside a VM as well. Defense in depth.
Running untrusted code in a wasm vm doesn’t add any extra defense over just using seccomp. It just adds unnecessary overhead and increases attack surface.
Earlier quoted context omitted.
Running untrusted code in a wasm vm doesn’t add any extra defense over just using seccomp. It just adds unnecessary overhead and increases attack surface.
Assuming that Intel / ARM microarch implementations are bug free, that is correct. In the real world there are no bug free implementations. Edit. This is the strategy Chrome sandboxing uses: a hardened runtime (JS/WASM) inside a seccomp enclosure. https://chromium.googlesource.com/chromiumos/docs/+/master/s...