iphydf 9d56db3a54 Avoid accessing uninitialised memory in net_crypto.
On x86 and x86_64, this change has no effect. On IA64, this fixes a
potential hardware exception. A function returned a partially initialised
value of aggregate type. The only caller of this function checks that the
value is valid before accessing it by testing the one definitely
initialised member. Therefore on x86 and derived architectures, there is
no uninitialised memory access. On IA64, with the regular calling
convention, the struct is allocated on the caller stack and passed as a
pointer, so there the uninitialised memory is also never accessed.
However, on calling conventions where one or more struct members past the
first byte are passed in registers or copied in memory, this call can
cause undefined behaviour.

Specifically, the value can contain a trap representation of the integers
(at the very least the 16 bit port) and cause a hardware exception and
SIGFPE in userland.

Regardless of the explanation above, this change fixes an instance of
undefined behaviour that just happened to be OK on all systems we tested
on.
2017-01-07 01:49:30 +00:00
2016-01-01 20:28:48 -05:00
2014-08-25 10:00:09 +04:00
2016-10-02 23:54:03 +01:00
2017-01-06 04:20:00 -08:00
2015-12-12 20:40:57 +01:00
2017-01-06 04:20:00 -08:00
2017-01-03 11:30:57 +00:00
2017-01-05 22:02:11 +00:00
2015-10-05 15:18:55 -07:00
2014-12-18 10:04:31 -05:00
2015-06-24 21:03:16 -04:00
2015-03-04 00:35:25 +01:00

Project Tox


Current build status: Build Status Current Coverage: Coverage Status

Website | Wiki | Blog | FAQ | Binaries/Downloads | Clients | Compiling

IRC Channels: Users: #tox@freenode, Developers: #toktok@freenode

Toxcore Development Roadmap

This Roadmap is somewhat tentative, but should give you a good idea of where we're going, and where we've been.

Currently unsorted, the following is intended to function as a discussion guide to developers/contributors.

In Progress

  • Toxcore
    • 100% unit testing
    • Make ToxAV stateless
    • Allow a single toxcore instance to handle multiple keypairs (or 'clients')
    • Consistent naming scheme throughout toxcore
    • Make toxcore stateless
  • Messenger
    • Improve group chat implementation
    • Improve A/V implementation
    • Multiple device support

Done

  • Create Toxcore
  • Create DHT
  • Create Onion
  • Implement Crypto
  • Create Messenger

Q&A:

What is Tox?

Tox is a fully encrypted, censor resistant, private, distributed network library with a focus on personal communications.

No, really, what's Tox?

It's a VERY secure Instant Messenger that supports Text, Audio/Video calls, group chats, audio group chats, and file transfers. There's dozens, but our advantage is we put security first, from day 1. We didn't decide to add it in after.

What are your goals with Tox?

We want Tox to be as simple as possible while remaining as secure as possible.

Documentation:

The Complex Stuff:

UDP vs. TCP

Tox must use UDP simply because hole punching with TCP is not as reliable. However, Tox does use TCP relays as a fallback if it encounters a firewall that prevents UDP hole punching.

Connecting & Communicating

Every peer is represented as a byte string (the public key [Tox ID] of the peer). By using torrent-style DHT, peers can find the IP of other peers by using their Tox ID. Once the IP is obtained, peers can initiate a secure connection with each other. Once the connection is made, peers can exchange messages, send files, start video chats, etc. using encrypted communications.

S
Description
No description provided
Readme GPL-3.0 54 MiB
Languages
C 76.3%
C++ 15.5%
Shell 2.1%
Starlark 1.4%
CMake 1.1%
Other 3.5%