uWebSocket supicious ?

[waghanza]

Hi @Fenny,

You inform me that the is some stories about uWebSocket @see https://medium.com/@rockstudillo/beware-of-uwebsockets-js-b51c92cac83f

Thanks for notification :stuck_out_tongue:

/cc @alexhultman @dalisoft @aadityataparia @jkyberneees

---

The idea here is to determine if uWebSocket based frameworks could be listed here

---

Personally, I have no idea of how npm registry works

[dalisoft]

It’s interesting. I didn’t noticed any mining or something similar yet. Let’s waiting answer from @alexhultman

[Fenny]

Regarding one of his sponsors I was talking about, here is some information for those interested. alleged price manipulation Tether Limited

I think we just want to make sure that any package is safe to use, compiling from source should be fine. Alex got talent and seems like a good programmer, but deleting comments / issues because you disagree is not cool.

Compile from source, case closed

[waghanza]

Sorry @alexhultman that this subject bother you.

The intention is not to hurt you or anything, but hear about you around this. It could be a safety issue, not only for uWebSocket.js, but with any library using it.

Also I'm not sure using injure helps in any way here.

The code of conduct https://github.com/the-benchmarker/web-frameworks/blob/master/CODE_OF_CONDUCT.md does not allow injure at all

Please change you language / behavior in face of this community.

[waghanza]

You are right @alexhultman, we are not any of your customer, but that does not mean you can not be polite.

As anyone here, you are doing opensource stuff, so you take some of your time to provide a solution to a problem. We are aware that is a time (and probably money) investment.

The subject here is not to be against you or what you are trying to achieve, but having some information to determine,, not your honesty, but safety of any library that use uWebSocket

[waghanza]

@alexhultman Please be polite. Even you disagree with some people (and I understand how boring could be the context) you have NOT to injure them the same is for you @Fenny -> if you have any facts to give us please be my guest

as far as I've read issues, posts ... 2 things are coming to me :

• an issue has been deleted on uWebSocket.js repo, and I think this is not fair
• the builds are made by AppVeyor/Travis. despite any idea I have about that, I don't find how this could be any security issue

for me @dalisoft and @aadityataparia libraries has their places here, and even you @alexhultman, their is not facts to give any reasonable argumentation about security failure here

I wish therefor to let this issue open as a debate, and even their is some conclusion, I'm not OK with I'll apply them

/cc @the-benchmarker/web-frameworks

[dalisoft]

I too got two sponsor (one sponsored me by hiring me) and one give me some money. I don't know them. I think uWebSockets.js sponsors pays only for high-performance backend server, not for any bad things, @Fenny do you think about this? From sponsoring both sides get benefits (author of library gets more motivated) and sponsor can get features they want. I don't care about this as i'm no sponsor, just one of user of uWebSockets.js.

@waghanza For me important is SECURITY, about npm version or other things i don't care, because these are happened in past. I just want to be sure it's really SECURE? (not mining or something) As 2K (monthly 2K nanoexpress downloads) users using my library on top of uWebSockets.js and they happy.

We all people, let's close discussion for me one word, YES or NO.

@alexhultman I even don't know how hard is make high-performance library/framework, because uWebSockets.js a lot of faster than any of libraries even i made for backend (including private servers), can you confirm uWebSockets.js is SAFE to USE? I think yes, but confirmation from author is better

@Fenny if you have any facts, please share with us, if it's just hype for disinformation peoples, please apologize from @alexhultman and @waghanza

I am didn't noticed any security issues yet.

Who isn't agree with me, you can DISLIKE my comment

Sorry for bad english if there any mistakes, i hope you're understand

[doanguyen]

The idea here is to determine if uWebSocket based frameworks could be listed here

I think the arguments worked on both sides, the author has his method to solve the problem (via using the mutable versioning), however, the method is not backed by any community because of the security risk. Even though the javascript library is deprecated so we could not see the log, I think we should not include the newer version of the javascript library to our benchmark.

On the other side, the C++ library is not a subject of the discussion and it has no problem with the building, packaging and distributing. I think if it possible then we can include it (https://github.com/uNetworking/uWebSockets)

[waghanza]

@dalisoft The fact is their is two things : history and security (and of course one could depend on the other).

1. History => For me not any problem with the library
2. Security => For me not any problem with the library

We can end / close this debate like https://github.com/the-benchmarker/web-frameworks/issues/1129#issuecomment-477328645, I remember at the time (but I golang communities) I had to remove iris and muxie here, because of security issues :heart:

@the-benchmarker/web-frameworks Please vote / react, and I'll remove / keep any libraries around uWebSocket.js here

Voting stop on 30th of january 2020

Please add a +1 for keeping, and -1 for removal

[waghanza]

@alexhultman please calm down, this is no helping, thus

[dalisoft]

@alexhultman Sorry, i'm not from any side, i'm just asked. I care about 2K users of my library.

[waghanza]

@alexhultman this issue is more about safety for this project, now that we have red your arguments, we can decide, as a community

[doanguyen]

@alexhultman Sorry, i'm not from any side, i'm just asked. I care about 2K users of my library.

He was quite clear that he does not care about that, including your 2K users now or later on. The thing is that if you use other famous libraries, such as React, Angular,... they also do not care about your users. The different is that they (react, angular...) had transparent records (or at least they tried) to make sure they do not (or will not) fuck you up now/later on.

Personally, I don't support these behaviours (from the author) even though he is a great programmer (this I don't know), and I think we should not go on with this javascript library. But this is my opinion only.

[dalisoft]

I keep using uWebSockets.js as core for my own library. Implementing adapter to switch is not a bad idea at all, but there i didn't found any alternative with same performance and adopted to Node.js

@waghanza If you want you can remove nanoexpress (-pro) from list of benchmarks

[waghanza]

@dalisoft depending on the result of https://github.com/the-benchmarker/web-frameworks/issues/2143#issuecomment-573656160, but in my opinion there is not real reasons to do so :stuck_out_tongue:

[Fenny]

@alexhultman, why did you delete all your comments?

[ghost]

Off-topic, if uWebSocket based frameworks were removed from the list, the author of the affected frameworks planning to switch to next language e.g. Go (since fasthttp is the highest and battle-tested)?

Feel free to downvote or remove if it's not a useful question to this issue.

[waghanza]

@vmark2020 This is clearly off-topic comments. The decision to switch or not to switch are up-to author and have more consequences from only performances

[waghanza]

any thoughts @vladfaust @ohler55 @OvermindDL1

[ohler55]

Whether dangerous or not I can't say but it does bring into question why releases can't be immutable like all other packages. I'd hate to exclude frameworks but if you can't count on a release being the same when you try it at home the benchmarks are meaningless. Fortunately, if getting a release from npm it should be immutable so that seems safe enough unless I am missing something.

[OvermindDL1]

Hmm, after a quick skim-reading the article and skim-reading the comments here a couple things:

Related to this project:

• That seems more of a framework for websockets rather than web serving, so I'm not sure it has a reason to be here unless websockets are starting to be benchmarked?

Unrelated to this project

Ignore this section if you are not interested in personal remarks

• Wow, someone against immutable releases?! That is an exceptionally questionable stance considering what's happened in the past. I don't see how anyone could possible hold such an opinion after knowing about the history of mutable releases... o.O
• Personally the author appears to have some public interaction issues; from a quick reading of his various content posted online (repo issues, archive.org, re-acquired history of the posts here, reddit, etc...) I'm guessing some form of social interaction disorder (narcissism, autism, etc...) and no one has managed to have him actually explain his stance in a way that shows that he understands the results of his actions on others in anything more than a surface way.

Suggestion

I'd vote to remove this on the grounds that it doesn't seem to be the right kind of thing being tested for a web framework as it's geared toward specifically websockets.

[ohler55]

I might have been confused as to the features of the uWebSocket. I made the assumption that it was in some part of web server as well as just a plug-in for Websockets. If that is not the case then I completely agree with @OvermindDL1, including there "unrelated" comments.

[OvermindDL1]

It 'is' a web server in so much you have to handle the HTTP packet protocol to be able to set up a websocket connection, and thus consequently it has the basics needed for web serving. Beyond that it doesn't handle the full HTTP spec properly from what I read, has no advanced dispatching mechanisms, etc... You 'can' do http with it, but that is very obviously not what it's designed for, it's designed for websocket work.

[dalisoft]

@OvermindDL1 It's great if there any alternative to uWebSockets.js, but theres no ones can provide add-on for Node.js. I love to see if there will be any alternative and can help from Node.js side. I tried, but not able to create add-on even for agoo-c by @ohler55 For Node.js developers only uWebSockets.js can provide high performance. Maybe i'm wrong

[waghanza]

@OvermindDL1 you're right. this tool seems named to be more for websocket things, but you can do exactly what we need here :stuck_out_tongue:

@dalisoft https://www.npmjs.com/package/ws is not suitable ?

@OvermindDL1 @ohler55 please vote on comment https://github.com/the-benchmarker/web-frameworks/issues/2143#issuecomment-573656160, it will be easier for me to decide of remove or else ...

---

EDIT This tools is NOT listed here, but frameworks using it :stuck_out_tongue:

[dalisoft]

@waghanza ws only for Websocket, i really love that library. Works fine everywhere i used. If ws could handle http requests, i can migrate

[aadityataparia]

FYI: I will not migrate. Feel free to remove sifrr if it is the consensus.

Also, I don't think there is any reason to remove it, as far as I understand this repo provides benchmarking and in no way endorses any frameworks listed here and users are free to choose framework they want taking other things in consideration. So it should be upto user to decide if any framework/library listed here is safe for them to use or not. And there seems to be no Contributing guideline that enforces the criteria of security/past problesm/ not listed on npm, etc for frameworks to be added in this repo. If you decide to remove this library, please add/update guideline with criteria needed to be listed.

[waghanza]

@aadityataparia I'm not sure this has to be in any Contributing guidelines, as any security issue COULD happen after introduction (guidelines do not help avoiding that).

The main goal of this project, is to help to take decision (by having real metrics). It's then our value (as a community) to enforce trust in any software part here.

The purpose of this thread is to decide whether the frameworks in which uWebSocket is part of, could be safe, nothing more

I'm not sure to make this in any guidelines but clarification in documentation could help.

Btw, thanks for the idea :heart:

[inlet3355]

I can see the vote outcome is even unless waghanza's vote should not be counted.

[waghanza]

@inlet3355 why my vote should not count ?

---

EDIT : Actually, 4 vs 4 is a perfect equality, so any removal will be proceed unless any other vote comes

[inlet3355]

You have previously allow uWebsocket framework to be used in this benchmark as it's interesting in this project, now you shouldn't take sides, it should be fair to let the community and others' votes be the decision maker.

Rather, only framework authors are eligible to vote in this case.

[ohler55]

It is @waghanza repo though. In the end he decides the rules. I think this is getting too involved and too complex. @waghanza, you have the inputs, make a decision and move on.

[waghanza]

@inlet3355 any member can vote :stuck_out_tongue:

@ohler55 you're right, I have to decide. I have not precise any timezone, so I'd prefer to let time past.

Now I can take a decision, as there is 4 vs 4 is https://github.com/the-benchmarker/web-frameworks/issues/2143#issuecomment-573656160, there is no reason to remove uWebSocket based frameworks from here