4 ms·

You can consider translating this library to Rust. As long as you can't or don't have the time commitment, we take this one over some fable or cool new library

You can consider translating this library to Rust. As long as you can't or don't have the time commitment, we take this one over some fable or cool new library somewhere. This one has 13 years proven battlefield use. Any big bugs already iron out or at least not so obvious. Rust may have safe memory coding built-in, it doesnt guarantee the coding to be 100% bug free or fully secure from zero day attacks. This is even worst off when the library say written in Rust just come out less than a couple years or even 6 mths.

omeid2 3y ago
> You can consider translating this library to Rust. There is no need for it. Rust already has libraries for http, websockets, and mqtt. > This one has 13 years proven battlefield use. And by lord this myth of "Old therefore must be battle-tested" must die. Case in appoint, I had to interact with a piece of software that used this library and it is as battle-tested as expecting HTTP headers in very specific casing! Here is a comment from some code I wrote circa 2020 to deal with this issue. So it is not hypothetical. // libwebsocket/1.X.X is naive about http headers // and expects them in a specific case but node.js as // permitted by http spec doesn't care about case. // this patches node.js http to send headers as expected // by libwebsocket/VAA const { setHeader } = http.OutgoingMessage.prototype; http.OutgoingMessage.prototype.setHeader = function (name, value) { name = name .replace(/\b(\w)/g, (match, submatch) => (submatch ? submatch.toUpperCase() : '')) .replace(/(websocket|Websocket)/g, () => 'WebSocket'); value = value.replace(/(websocket|Websocket)/g, () => 'WebSocket'); setHeader.call(this, name, value); };
- lelanthran 3y ago
  >>> With Rust and C++, even for embedded systems, what is the use case for starting a new project that does binary encoding and network with such an unsafe language like C? >> Rust may have safe memory coding built-in, it doesnt guarantee the coding to be 100% bug free or fully secure from zero day attacks. > Case in appoint, I had to interact with a piece of software that used this library and it is as battle-tested as expecting HTTP headers in very specific casing! How would rewriting in $SOMETHING_OTHER_THAN_C help with this bug? This is a bug that would have happened in any language. After all, Gow8876 was very specific about what he was referring to ("memory safety" bugs), because you were very specific about what you were referring to ("unsafe language").
  - omeid2 3y ago
    > After all, Gow8876 was very specific about what he was referring to ("memory safety" bugs), because you were very specific about what you were referring to ("unsafe language"). I pointed out this defect because handling HTTP headers "correctly" is such a basic requirement for a websocket library, yet it failed at it, so the claim for "13 years proven battlefield use" is baseless and only based on the fallacy of "it is old therefore battle-tested". > Rust may have safe memory coding built-in, it doesnt guarantee the coding to be 100% bug free or fully secure from zero day attacks. No one is making this absurd claim, but what we know is that majority of RCE bugs are memory related.

omeid2 3y ago

> You can consider translating this library to Rust. There is no need for it. Rust already has libraries for http, websockets, and mqtt. > This one has 13 years proven battlefield use. And by lord this myth of "Old therefore must be battle-tested" must die. Case in appoint, I had to interact with a piece of software that used this library and it is as battle-tested as expecting HTTP headers in very specific casing! Here is a comment from some code I wrote circa 2020 to deal with this issue. So it is not hypothetical. // libwebsocket/1.X.X is naive about http headers // and expects them in a specific case but node.js as // permitted by http spec doesn't care about case. // this patches node.js http to send headers as expected // by libwebsocket/VAA const { setHeader } = http.OutgoingMessage.prototype; http.OutgoingMessage.prototype.setHeader = function (name, value) { name = name .replace(/\b(\w)/g, (match, submatch) => (submatch ? submatch.toUpperCase() : '')) .replace(/(websocket|Websocket)/g, () => 'WebSocket'); value = value.replace(/(websocket|Websocket)/g, () => 'WebSocket'); setHeader.call(this, name, value); };

lelanthran 3y ago
>>> With Rust and C++, even for embedded systems, what is the use case for starting a new project that does binary encoding and network with such an unsafe language like C? >> Rust may have safe memory coding built-in, it doesnt guarantee the coding to be 100% bug free or fully secure from zero day attacks. > Case in appoint, I had to interact with a piece of software that used this library and it is as battle-tested as expecting HTTP headers in very specific casing! How would rewriting in $SOMETHING_OTHER_THAN_C help with this bug? This is a bug that would have happened in any language. After all, Gow8876 was very specific about what he was referring to ("memory safety" bugs), because you were very specific about what you were referring to ("unsafe language").
- omeid2 3y ago
  > After all, Gow8876 was very specific about what he was referring to ("memory safety" bugs), because you were very specific about what you were referring to ("unsafe language"). I pointed out this defect because handling HTTP headers "correctly" is such a basic requirement for a websocket library, yet it failed at it, so the claim for "13 years proven battlefield use" is baseless and only based on the fallacy of "it is old therefore battle-tested". > Rust may have safe memory coding built-in, it doesnt guarantee the coding to be 100% bug free or fully secure from zero day attacks. No one is making this absurd claim, but what we know is that majority of RCE bugs are memory related.