4 ms·

This looks like a great project! I'm curious about the following caveat from the readme, however: "Data flowing through mist is NOT touched in anyway. It is no

This looks like a great project! I'm curious about the following caveat from the readme, however: "Data flowing through mist is NOT touched in anyway. It is not verified in any way, but it MUST NOT contain a newline character as this will break the mist protocol." I haven't read the code yet, but my gut reaction is that this suggests it would be possible to inject commands using malicious user input. Given the caveat, this may be allowed for by your threat model, but it may be worth some effort to mitigate. EDIT: To clarify, this may not be the case at all, in which case I'd be curious to hear why this restriction is in place.

tylerflint 11y ago
This is referring to messaging being sent through mist. Mist doesn't care what the data looks like, and won't transform it. Currently the public-facing websocket client is not allowed to publish messages until this is mitigated, as you mentioned. Any feedback here would be appreciated.
- ShaneWilton 11y ago
  Cool, thanks for the response! If I get a chance later, I'll look through the code and see if anything jumps out at me.
- zrail 11y ago
  Netstrings are for this exact use case: http://cr.yp.to/proto/netstrings.txt http://cr.yp.to/proto/netstrings.txt
  - viraptor 11y ago
    Actually this proposal is quite bad compared to simple "<4 bytes size><size bytes contents>". If you use netstrings recursively like djb recommends, you will end up copying / reallocing the strings many times. Since your top-level length depends on the lower level length, you cannot send it without actually calculating the whole contents. Asn1 DER has the same issue because of the weird size encoding. RIFF is a bit better https://en.wikipedia.org/wiki/Resource_Interchange_File_Format https://en.wikipedia.org/wiki/Resource_Interchange_File_Form... with strict length,tag,contents format.
    - zrail 11y ago
      Wasn't suggesting they use the recursive feature. Just a flat netstring for the data segments, sort of how the Redis and Memcached protocols work.
  - krakensden 11y ago
    I think tnetstrings are a pretty reasonable improvement, too https://github.com/rfk/tnetstring/ https://github.com/rfk/tnetstring/

tylerflint 11y ago

This is referring to messaging being sent through mist. Mist doesn't care what the data looks like, and won't transform it. Currently the public-facing websocket client is not allowed to publish messages until this is mitigated, as you mentioned. Any feedback here would be appreciated.

ShaneWilton 11y ago
Cool, thanks for the response! If I get a chance later, I'll look through the code and see if anything jumps out at me.
zrail 11y ago
Netstrings are for this exact use case: http://cr.yp.to/proto/netstrings.txt http://cr.yp.to/proto/netstrings.txt
- viraptor 11y ago
  Actually this proposal is quite bad compared to simple "<4 bytes size><size bytes contents>". If you use netstrings recursively like djb recommends, you will end up copying / reallocing the strings many times. Since your top-level length depends on the lower level length, you cannot send it without actually calculating the whole contents. Asn1 DER has the same issue because of the weird size encoding. RIFF is a bit better https://en.wikipedia.org/wiki/Resource_Interchange_File_Format https://en.wikipedia.org/wiki/Resource_Interchange_File_Form... with strict length,tag,contents format.
  - zrail 11y ago
    Wasn't suggesting they use the recursive feature. Just a flat netstring for the data segments, sort of how the Redis and Memcached protocols work.
- krakensden 11y ago
  I think tnetstrings are a pretty reasonable improvement, too https://github.com/rfk/tnetstring/ https://github.com/rfk/tnetstring/