Hacker News Reader

Comment by mfer | Hacker News Reader

> Wasmer, by necessity, design, and passion lives and breathes Wasm and open source.

> As is dictated by our commitment to open source and the precedent of social alignment set by WebAssembly...

> Although all these events still do not portray Wasmer in the best light, I hope they can at least assuage the understandable concerns of our community that we had acted in a way so fundamentally contrary to the values of open source and WebAssembly in particular.

Wasmer recently recently released a closed source wasm package manager. Something doesn't seem right. Anyone feel something is off here?

View on HN

There is nothing[0] suspicious[1] about[2] Wasmer.

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

[1] https://www.reddit.com/r/programming/comments/o1838v/the_web...

[2] https://news.ycombinator.com/item?id=24904829

> But you need to know that Wasmer and its sibling projects will stay free forever. We are open source lovers, all of us, and we have a strong background on working on open source projects before joining Wasmer too.

That's great. I'm sure the closed source paid 10x faster editions of the graphene Python GraphQL server written by Syrus "CEO of Graphene" and CEO of wasmer will be open sourced in this spirit.

https://github.com/graphql-python/graphene/issues/268#issuec...

http://graphql-quiver.com/

Bummer. What an unfortunate comment.

Many people in the Python GraphQL ecosystem are very aware of how much I pushed that ecosystem forward (in fact, I created it!) and actually cheered for the success of Quiver [1]. Probably downloads will speak louder than any words: Graphene has 1/5th of the downloads of Django (~1.2 million per month [2]), all on the spirit of an open community that is governed by many more people than myself.

If you want an open alternative to Quiver, you can start by investing your time creating it. But you are not entitled on other people's time doing it for you for free. As people say in the US: "Put your money (or time) where your mouth is".

[1] https://news.ycombinator.com/item?id=17568848

[2] https://pypistats.org/packages/graphene

I have no problems paying for good services. Is quiver still available and supported? When I checked the demo website a few weeks ago it seemed a bit abandoned. [0] We seem to be doing well enough by disabling middleware promise wrapping via middleware manager [1]. Our median graphQL API response times got 2x faster with that config change. However, IIRC we are still seeing around 150 promises in one GraphQL request when I'd like to see around 1. I am interested in quiver for that reason.

Anyway, the problem isn't about charging for your work. It's about having a track record of charging for closed source additions to your own open source software platform meanwhile saying wasmer and sibling projects will be free forever as if that's how it's always been with everything else.

[0]: https://graphql-quiver.com/benchmarks/

[1]: https://github.com/graphql-python/graphql-core-legacy/blob/m...

> It's about having a track record of charging for closed source additions to your own open source software platform

This is completely false. In fact, it has been rather the opposite. Thanks to Quiver I did improved a lot of things on the open-source GraphQL-core that benefited the whole community.

Quiver was built as a completely new product, and to be crystal clear: it never took any open-source bits out of Graphene or GraphQL-core. Basically, anything that was open-source did continue being open-source. That's as true for Graphene as it is for Wasmer.

I'm genuinely curious. On which ground you based your allegations?

I don't think having closed source projects contradicts that statement. You're allowed to love open source and make some open source things while still keeping other things closed source.

I don't think it's too reasonable to expect that every open-source-friendly company never releases a closed source project. Or at least I don't find it weird that an open-source-friendly company might have one closed source project. Their core project, wasmer, is open-source after all.

The WAPM backend is closed-source for now.

However, the API layer based on GraphQL and the CLI are completely open for anyone to use: https://registry.wapm.io/graphql https://github.com/wasmerio/wapm-cli

If anyone wants to replicate the WebAssembly Package Manager locally please send me an email to syrus@wasmer.io so we can start a discussion around a potential open-source path for it :)

EDIT: removed "for security reasons among other things" as it might imply WAPM is not secure, and that's definitely not the case

Closed source for security reasons?

Do you mean it would not be secure if people were able to see the source?

Open-source code is obviously easier to exploit than closed source one. But that doesn't imply necessarily the existence of security bugs.

For example, we might be using a dependency that is vulnerable to exploits or have an exploit in our own code that opens a security breach (hopefully not!).

As an open-source maintainer I like to open projects for which the code-quality is high, and this implies doing a deep and thorough review of the codebase before open-sourcing.

Open-source code is not in fact easier to exploit than closed-source code is. Security and openness are mostly orthogonal.

This is often repeated but it’s just obviously not true. It’s much easier to figure out how to exploit a server if I have its source. If I don’t, I have to throw a bunch of stuff at the wall and hope something sticks.

If I’m in the situation where I have a binary of a server without the source, I have to pay the cost of using ghidra or IDA for a few hours or days (or weeks) to figure out how the software is structured before I can come up with an exploit. If I’m dealing with an open source target that’s a cost I don’t have to pay.

> Open-source code is not in fact easier to exploit than closed-source code is

Not sure if I agree with this. Obscure systems are usually harder to hack as they require an extra effort on discoverability that open systems don't have.

Easier to exploit != more exploitable. One is about the threshold to discover an exploit, the other is about the total exploitable bugs.

In my view, the "hackability level" is the same for both open and closed-source projects. Making something close it doesn't make it less hackeable, it just makes the threshold to discover bugs higher.

Also, one may argue that with open-source projects you may be able to fix more bugs since those are in the open and more people can report them (thus, more secure). I think it really depends on the contribution level and where the codebase is at to see if security might be a concern or not.

> Security and openness are mostly orthogonal.

But I mostly agree with this ;)

Most people would say that reducing the threshold to discover security bugs is a good thing.

Security through obscurity is not security. The source WAS open, any bugs in it then are still discoverable. Opening source can actually make things more secure, the whole "many eyes" thing.

The interesting thing in this argument is that the first person is positing axiomatically that closed source is more secure, the second person is positing that open/closed largely doesn’t matter and finally your position axiomatically is that open is more secured.

We’ve known since the 70s that you (provably) can’t trust source code. We know experientially that it’s easier to diagnose code than programs. We also know experientially that the teams involved have a dramatic effect on the security of the outcomes.

How will we ever decide which of our three contestants will win?

Not quite. tptacek says "Most people would say that reducing the threshold to discover security bugs is a good thing." I think that restating what tptacek said earlier, "mostly orthoganal", to "largely doesn't matter", loses some of the meaning.

One way of seeing it is that it's mostly orthaganal at a level of all software out there, but that for those who make a serious effort to be secure, there is a lot of benefit to being open source.

There's Linus's Law, "given enough eyeballs, all bugs are shallow". I think if the maintainers of Linux didn't meaningfully address security concerns, it would just mean they were doing a bit better at whack-a-mole. You see this in popular open source projects like WordPress.

So I think that's why a reader might think tptacek's two comments don't jibe with each other. If you are given a choice between an open source and a closed source application, you wouldn't just assume one is more secure than another. However, if you were starting off to make a secure system, it would be a good idea to make it open source.

Heartbleed proved that the “many eyes” theory doesn’t always work in practice. It was in the codebase for years and no one noticed.

> Heartbleed proved that the “many eyes” theory doesn’t always work in practice. It was in the codebase for years and no one noticed.

It proved that FOSS isn't infallible, which I hope isn't that great a shock. To argue that it weakens the general argument, you would need to present a similar TLS library which avoided exploits by being closed source.

The person you're responding to could simply provide every closed source TLS library as an example, because Heartbleed (a memory leak caused by implementing a TLS feature nobody was using) was exclusive to OpenSSL.

That's absurd; we're comparing the rate of exploits, not whether the same exact exploit exists. By that logic, I can say that OpenSSL is perfect because it doesn't have (quick search) https://docs.microsoft.com/en-us/security-updates/SecurityBu...

It's not as absurd as it sounds, because a closed-source TLS library had less impetus to implement the extension that caused the vulnerability. But mostly I'm just making a point about the quality of the argument upthread.

There was also the Apple “goto fail” bug in their open source TLS code[0], which was so shockingly obvious that it would have been found by compiler warnings, yet it was not.

I myself have on occasion found high priority bugs (not security issues) in open source projects with many eyeballs, simply by turning on additional compiler warnings. The fruit out there hangs very low.

Openness counts for nothing if nobody is reading the code. Open is better than being closed source but the difference is marginal. The real difference is made by having the code reviewed by security professionals, and by how the project is maintained/lead, and those are orthogonal to open/closed source.

[0] https://www.imperialviolet.org/2014/02/22/applebug.html

> Wasmer recently recently released a closed source wasm package manager. Something doesn't seem right. Anyone feel something is off here?

I have to agree. Are there any open source package managers similar to cargo?

Reply on news.ycombinator.com