4 ms·
My one experience with the Tox project was that I made a few (I thought) constructive suggestions. First, I suggested they use some form of static analysis or p
by jbangert 12y ago
My one experience with the Tox project was that I made a few (I thought) constructive suggestions. First, I suggested they use some form of static analysis or perhaps a 'safer' language to implement their core functionality - such as Rust or Go, instead of rather messy (at the time) C code.
Furthermore, having spent a lot of time researching parsers and how parser differentials can affect the security of systems, I suggested they use some tools, such as protocol buffers, to eliminate handwritten parsing code. The response I got was rather disheartening and downright hostile - it boiled down to the fact that protocol buffers involves C++ code which they are a priori against, without actually engaging in a factual argument (I wrote an article in the current USENIX login/ last years OSDI about parsers for binary protocols for anyone interested in background: https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-bangert.pdf https://www.usenix.org/system/files/conference/osdi14/osdi14... and github.com/jbangert/nail)
- dethstar 12y agoThere was a tox-core rewrite in Rust[1], but it's been abandoned. According to the author until Tox gets proper doc. https://github.com/mahkoh/Xot https://github.com/mahkoh/Xot
- stingraycharles 12y agoOur of interest, could you share the url to the discussion?
- jbangert 12y agohttps://github.com/irungentoo/toxcore/issues/137 https://github.com/irungentoo/toxcore/issues/137
- mplewis 12y agoThey wrote their own parser and think it's more secure than Google-backed protobufs? That's unbelievable.
- kevan 12y agoThe last reply to the issue: "The Tox protocol is very easy to parse in C which means little chance of issues." Building a homegrown parser and simultaneously expecting not to have security issues, that's true confidence.
- irungentoo 12y agoIf you actually read the code you will see that it's true. The parsing is dead simple and written in a way that mistakes are very unlikely.
- nfkd 12y agoThat's a really bold statement to make. And why not use a proven secure parser in the first place?
- sillysaurus3 12y ago(EDIT: Note that everyone was proceeding under the assumption that silentbits was a Tox dev, but that's apparently not true, as was corrected below. I wonder it that calls into question the original comment...) From the github conversation: silentbits said: "Nobody is going to risk using an external parser in such critical code." jbangert replied: "What do you mean? not invented here? Google's core engineers are better (and their code gets more review, attention, etc). than anything we can produce." silentbits said: "You have few exchange protocols: ITCH, OUTCH (NASDAQ), UTP MD, XDP (NYSE), PITCH (BATS). These protocols are in binary form and very easy to convert from/to C/C++ struct. If you produce critical software you want to have a code that you can be verified and tested. You can of course find external parsers for this, but all serious players do their own parsers. The only exception might be FPGAs implementation where whole is written in HDL (VHDL, verilog)." Am I correct in assessing that the reason this is troubling is because the tox devs are saying "Everyone else is writing their own parsers, so we should write our own parsers too"? I don't know. If you want to criticize a software project for writing their own parser, you'll also need to criticize Tarsnap, since they write their own too. Yet Tarsnap is basically the gold standard in native security software. So either Tarsnap is being equally crazy, or it's not so crazy after all. I wonder which one is the case?
- Jfreegman 12y agoI should point out that silentbits is not a Tox dev. He was only expressing his personal opinion on that matter.
- sillysaurus3 12y agoMy mistake, sorry. (And apparently everyone else is making the same mistake too...) I've edited my comment for clarity. Did Tox devs express anything on the matter? It's very hard to substantiate all of this without someone who knows the Tox project. For example, the last reply was "The Tox protocol is very easy to parse in C which means little chance of issues." Is that from a Tox dev?
- Jfreegman 12y ago
- lipnitsk 12y agoThere are also protocol buffers libraries for and in C code, such as the protobuf-c library: https://github.com/protobuf-c/protobuf-c https://github.com/protobuf-c/protobuf-c
- sillysaurus3 12y agoThe response I got was rather disheartening and downright hostile - it boiled down to the fact that protocol buffers involves C++ code which they are a priori against Being against C++ isn't inherently a bad thing. For example, Tarsnap probably won't ever use C++ code. I can't read your PDF because of an SSL certificate error.
- jbangert 12y agoWeird, it works here. I put a copy on my webpage at http://csail.mit.edu/~julian/papers/login_nail.pdf http://csail.mit.edu/~julian/papers/login_nail.pdf As has been pointed out below, there are many C bindings for Protobuf (and my argument was that using something like protobuf allows reimplementing the protocol).
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- irungentoo 12y agoFirst of all the choice of C is because it was the language I was the most confidant writing secure code in. I'm not going to learn a new language and then right away start try to write secure code with it. Clang has some great tools I use like the various sanitizers. Static analysis sucks and almost never finds any real issues but we still use it. If you think toxcore should use protocol buffers, feel free to port it. This is an open source project and contributions are welcome. If you do a better job than me then I will merge your contribution. We are at #tox-dev on freenode.
- nfkd 12y agoBut why create your own parser instead of using proven-secure ones? Sounds like NIH Syndrome to me.