ffi-tox 0.1.1 → 0.1.3

data/ProjectTox-Core/docs/TODO

@@ -0,0 +1,62 @@
+TODO list.
+
+[IN PROGRESS] Add what is left to do to the TODO list.
+
+Networking:
+    [NOT STARTED] UPnP port forwarding.
+    [NOT STARTED] NAT-PMP port forwarding.
+
+DHT:
+    [ALMOST DONE] Metadata collection prevention. (docs/Prevent_Tracking.txt)
+    [IN PROGRESS] Hardening against attacks.
+    [IN PROGRESS] Optimizing the code.
+
+Lossless UDP:
+    [DONE] Increase data send/receive rates.
+
+[IN PROGRESS] Massive IRC like group chats (text only)
+    [DONE] Networking base.
+    [NOT STARTED] Syncing chat state between clients (nicknames, list of who is in chat, etc...)
+    [NOT STARTED] Make clients sign their messages so that peers can't modify them.
+
+[IN PROGRESS] Audio/Video
+    [DONE] encoding/streaming/decoding
+    [DONE] Call initiation
+    [DONE] Encryption
+    [IN PROGRESS] Auditing.
+    [NEEDS TESTING] Video packet splitting.
+    [IN PROGRESS] Prevent audio skew (seems to be easily solvable client side.)
+    [IN PROGRESS] Group chats.
+
+Friend_requests.c:
+    [NOT STARTED] What happens when a friend request is received needs to be changed.
+    [NOT STARTED] Add multiple nospam functionality.
+
+[DONE] File transfers
+[NOT STARTED] Offline messaging
+[NOT STARTED] Friends list syncing
+[IN PROGRESS] IPV6 support
+    [DONE] Networking
+    [DONE] DHT + Messenger
+    [NOT STARTED] Group chats (They work with IPv6 but some things need to be tested.)
+
+
+[IN PROGRESS] Make toxcore thread safe.
+
+[NOT STARTED] Make the core save/datafile portable across client versions/different processor architectures.
+
+[MOSTLY DONE] A way for people to connect to people on Tox if they are behind a bad NAT that 
+blocks UDP (or is just unpunchable) (docs/TCP_Network.txt)
+
+[NEEDS TESTING] Make the save made with tox_save_encrypted(...) harder to brute force.
+See: (https://github.com/jencka/ProjectTox-libtoxdata)
+
+[IN PROGRESS] GUI (no official one chosen yet, a list of promising ones follows)
+https://github.com/notsecure/uTox
+https://github.com/naxuroqa/Venom
+https://github.com/Impyy/Toxy
+https://github.com/lehitoskin/blight
+https://github.com/nurupo/ProjectTox-Qt-GUI
+https://github.com/Astonex/Antox
+
+[NOT STARTED] Security audit from professionals

data/ProjectTox-Core/docs/Tox_middle_level_network_protocol.txt

@@ -0,0 +1,120 @@
+The TCP client and TCP server part are in a state that can be considered 
+feature complete. Why doesn't Tox support TCP yet even if those parts are 
+complete?
+
+The answer is that a way to ensure a smooth switchover between the TCP and UDP 
+needs to be added. If Tox first connects to the other user using TCP but then 
+due to pure chance manages to connect using the faster direct UDP connection 
+Tox must switch seamlessly from the TCP to the UDP connection without there 
+being any data loss or the other user going offline and then back online. The 
+transition must be seamless whatever both connected users are doing be it 
+transferring files or simply chatting together.
+
+Possible evil/bad or simply TCP relays going offline must not impact the 
+connection between both clients.
+
+Typically Tox will use more than one TCP relay to connect to other peers for 
+maximum connection stability which means there must be a way for Tox to take 
+advantage of multiple relays in a way that the user will never be aware if one
+of them goes offline/tries to slow down the connection/decides to corrupt 
+packets/etc..
+
+To accomplish this Tox needs something between the low level protocol (TCP) and 
+high level Tox messaging protocol hence the name middle level.
+
+The plan is to move some functionality from lossless_UDP to a higher level: 
+more specifically the functionality for detecting which packets a peer is 
+missing and the ability to request and send them again. lossless UDP uses plain 
+text packets to request missing packets from the other peer while Tox is 
+currently designed to kill the connection if any packet tampering is detected. 
+This works very well when connecting directly with someone because if the 
+attacker can modify packets it means he can kill your connection anyways. With 
+TCP relays however that is not the case as such the packets used to request 
+missing packets must be encrypted. If it is detected that a packet has been 
+tampered, the connection must stay intact while the evil relay must be 
+disconnected from and replaced with a good relay, the behavior must be the same 
+as if the relay had just suddenly gone online. Of course something to protect 
+from evil "friends" framing relays must also be implemented.
+
+Detailed implementation details:
+
+cookie request packet:
+[uint8_t 24][Senders DHT Public key (32 bytes)][Random nonce (24 
+bytes)][Encrypted message containing: [Senders real public key (32 
+bytes)][padding (32 bytes)][uint64_t number (must be sent 
+back untouched in cookie response)]]
+Encrypted message is encrypted with sender DHT private key, receivers DHT
+public key and the nonce.
+
+cookie response packet:
+[uint8_t 25][Random nonce (24 bytes)][Encrypted message containing: 
+[Cookie][uint64_t number (that was sent in the request)]]
+Encrypted message is encrypted with sender DHT private key, receivers DHT
+public key and the nonce.
+
+The Cookie should be basically:
+[nonce][encrypted data:[uint64_t time][Senders real public key (32 
+bytes)][Senders dht public key (32 bytes)]]
+
+Handshake packet:
+[uint8_t 26][Cookie][nonce][Encrypted message containing: [random 24 bytes base 
+nonce][session public key of the peer (32 bytes)][sha512 hash of the entire 
+Cookie sitting outside the encrypted part][Other Cookie (used by the other to 
+respond to the handshake packet)]]
+
+The handshake packet is encrypted using the real private key of the sender, the 
+real public key of the receiver and the nonce.
+
+
+Alice wants to connect to bob.
+
+Alice sends a cookie request packet to bob and gets a cookie response back.
+
+Alice then generates a nonce and a temporary public/private keypair.
+
+Alice then takes that nonce and just generated private key, the obtained 
+cookie, creates a new cookie and puts them in a handshake packet which she 
+sends to bob.
+
+Bob gets the handshake packet, accepts the connection request, then generates a 
+nonce and a temporary public/private keypair and sends a handshake packet back 
+with this just generated information and with the cookie field being the Other 
+Cookie contained in the received handshake.
+
+Both then use these temporary keys to generate the session key with which every 
+data packet sent and received will be encrypted and decrypted. The nonce sent 
+in the handshake will be used to encrypt the first data packet sent, the nonce 
++ 1 the second, the nonce + 2 the third and so on.
+
+Data packets:
+
+[uint8_t 27][uint16_t (in network byte order) the last 2 bytes of the nonce 
+used to encrypt this][encrypted with the session key and a nonce:[plain data]]
+
+Plain data in the data packets:
+
+[uint32_t our recvbuffers buffer_start, (highest packet number handled + 
+1)][uint32_t packet number if lossless, our sendbuffer buffer_end if 
+lossy][data]
+
+data ids:
+0: padding (skipped until we hit a non zero (data id) byte)
+1: packet request packet (lossy packet)
+2: connection kill packet (lossy packet) (tells the other that the connection is over)
+...
+16+: reserved for Messenger usage (lossless packets).
+192+: reserved for Messenger usage (lossy packets).
+255: reserved for Messenger usage (lossless packet)
+
+packet request packet: [uint8_t (1)][uint8_t num][uint8_t num][uint8_t 
+num]...[uint8_t num]
+
+the list of nums are a list of packet numbers the other is requesting.
+to get the real packet numbers from this list take the recvbuffers buffer_start
+from the packet, subtract 1 to it and put it in packet_num then start from the
+beginning of the num list: if num is zero, add 255 to packet_num then do the
+next num. if num isn't zero, add its value to packet_num, note that the other
+has requested we send this packet again to them then continue to the next num in
+the list.
+
+

data/ProjectTox-Core/docs/av_api.md

@@ -0,0 +1,194 @@
+#A/V API reference
+
+##Take toxmsi/phone.c as a reference
+
+###Initialization:
+
+```
+phone_t* initPhone(uint16_t _listen_port, uint16_t _send_port);
+```
+
+function initializes sample phone. _listen_port and _send_port are variables only meant
+for local testing. You will not have to do anything regarding to that since
+everything will be started within a mesenger.
+
+
+Phone requires one msi session and two rtp sessions ( one for audio and one for
+video ). 
+
+```
+msi_session_t* msi_init_session( void* _core_handler, const uint8_t* _user_agent );
+```
+
+initializes msi session.
+Params:
+
+```
+void* _core_handler - pointer to an object handling networking,
+const uint8_t* _user_agent - string describing phone client version.
+```
+
+Return value:
+msi_session_t* - pointer to a newly created msi session handler.
+
+###msi_session_t reference:
+
+How to handle msi session:
+Controlling is done via callbacks and action handlers.
+First register callbacks for every state/action received and make sure
+NOT TO PLACE SOMETHING LIKE LOOPS THAT TAKES A LOT OF TIME TO EXECUTE; every callback is being called 
+directly from event loop. You can find examples in phone.c.
+
+Register callbacks: 
+```
+void msi_register_callback_call_started ( MCALLBACK );
+void msi_register_callback_call_canceled ( MCALLBACK );
+void msi_register_callback_call_rejected ( MCALLBACK );
+void msi_register_callback_call_ended ( MCALLBACK );
+
+void msi_register_callback_recv_invite ( MCALLBACK );
+void msi_register_callback_recv_ringing ( MCALLBACK );
+void msi_register_callback_recv_starting ( MCALLBACK );
+void msi_register_callback_recv_ending ( MCALLBACK );
+void msi_register_callback_recv_error ( MCALLBACK );
+
+void msi_register_callback_requ_timeout ( MCALLBACK );
+```
+
+MCALLBACK is defined as: void (*callback) (void* _arg)
+msi_session_t* handler is being thrown as \_arg so you can use that and \_agent_handler to get to your own phone handler
+directly from callback.
+
+
+Actions:
+
+```
+int msi_invite ( msi_session_t* _session, call_type _call_type, uint32_t _timeoutms );
+```
+
+Sends call invite. Before calling/sending invite msi_session_t::_friend_id is needed to be set or else
+it will not work. _call_type is type of the call ( Audio/Video ) and _timeoutms is how long 
+will poll wait until request is terminated.
+
+```
+int msi_hangup ( msi_session_t* _session );
+```
+Hangs up active call
+
+```
+int msi_answer ( msi_session_t* _session, call_type _call_type );
+```
+Answer incomming call. _call_type set's callee call type.
+
+```
+int msi_cancel ( msi_session_t* _session );
+```
+Cancel current request.
+
+```
+int msi_reject ( msi_session_t* _session );
+```
+Reject incomming call.
+
+
+###Now for rtp:
+
+You will need 2 sessions; one for audio one for video.
+You start them with:
+```
+rtp_session_t* rtp_init_session ( int _max_users, int _multi_session );
+```
+
+Params:
+```
+int _max_users - max users. -1 if undefined
+int _multi_session - any positive number means uses multi session; -1 if not.
+```
+
+Return value:
+```
+rtp_session_t* - pointer to a newly created rtp session handler.
+```
+
+###How to handle rtp session:
+Take a look at
+```
+void* phone_handle_media_transport_poll ( void* _hmtc_args_p ) in phone.c
+```
+on example. Basically what you do is just receive a message via:
+```
+struct rtp_msg_s* rtp_recv_msg ( rtp_session_t* _session );
+```
+
+and then you use payload within the rtp_msg_s struct. Don't forget to deallocate it with:
+void rtp_free_msg ( rtp_session_t* _session, struct rtp_msg_s* _msg );
+Receiving should be thread safe so don't worry about that.
+
+When you capture and encode a payload you want to send it ( obviously ).
+
+first create a new message with:
+```
+struct rtp_msg_s* rtp_msg_new ( rtp_session_t* _session, const uint8_t* _data, uint32_t _length );
+```
+
+and then send it with:
+```
+int rtp_send_msg ( rtp_session_t* _session, struct rtp_msg_s* _msg, void* _core_handler );
+```
+
+_core_handler is the same network handler as in msi_session_s struct.
+
+
+##A/V initialization:
+```
+int init_receive_audio(codec_state *cs);
+int init_receive_video(codec_state *cs);
+Initialises the A/V decoders. On failure it will print the reason and return 0. On success it will return 1.
+
+int init_send_audio(codec_state *cs);
+int init_send_video(codec_state *cs);
+Initialises the A/V encoders. On failure it will print the reason and return 0. On success it will return 1.
+init_send_audio will also let the user select an input device. init_send_video will determine the webcam's output codec and initialise the appropriate decoder.
+
+int video_encoder_refresh(codec_state *cs, int bps);
+Reinitialises the video encoder with a new bitrate. ffmpeg does not expose the needed VP8 feature to change the bitrate on the fly, so this serves as a workaround.
+In the future, VP8 should be used directly and ffmpeg should be dropped from the dependencies.
+The variable bps is the required bitrate in bits per second.
+```
+
+
+###A/V encoding/decoding:
+```
+void *encode_video_thread(void *arg);
+```
+Spawns the video encoding thread. The argument should hold a pointer to a codec_state.
+This function should only be called if video encoding is supported (when init_send_video returns 1).
+Each video frame gets encoded into a packet, which is sent via RTP. Every 60 frames a new bidirectional interframe is encoded.
+```
+void *encode_audio_thread(void *arg);
+```
+Spawns the audio encoding thread. The argument should hold a pointer to a codec_state.
+This function should only be called if audio encoding is supported (when init_send_audio returns 1).
+Audio frames are read from the selected audio capture device during intitialisation. This audio capturing can be rerouted to a different device on the fly.
+Each audio frame is encoded into a packet, and sent via RTP. All audio frames have the same amount of samples, which is defined in AV_codec.h.
+```
+int video_decoder_refresh(codec_state *cs, int width, int height);
+```
+Sets the SDL window dimensions and creates a pixel buffer with the requested size. It also creates a scaling context, which will be used to convert the input image format to YUV420P.
+
+```
+void *decode_video_thread(void *arg);
+```
+Spawns a video decoding thread. The argument should hold a pointer to a codec_state. The codec_state is assumed to contain a successfully initialised video decoder.
+This function reads video packets and feeds them to the video decoder. If the video frame's resolution has changed, video_decoder_refresh() is called. Afterwards, the frame is displayed on the SDL window.
+```
+void *decode_audio_thread(void *arg);
+```
+Spawns an audio decoding thread. The argument should hold a pointer to a codec_state. The codec_state is assumed to contain a successfully initialised audio decoder.
+All received audio packets are pushed into a jitter buffer and are reordered. If there is a missing packet, or a packet has arrived too late, it is treated as a lost packet and the audio decoder is informed of the packet loss. The audio decoder will then try to reconstruct the lost packet, based on information from previous packets.
+Audio is played on the default OpenAL output device.
+
+
+If you have any more qustions/bug reports/feature request contact the following users on the irc channel #tox-dev on irc.freenode.net:
+For RTP and MSI: mannol
+For audio and video: Martijnvdc

data/ProjectTox-Core/libtoxav.pc.in

@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libtoxav
+Description: Tox A/V library
+Requires:
+Version: @PACKAGE_VERSION@
+Libs: -L${libdir} -ltoxav @AV_LIBS@
+Cflags: -I${includedir}

data/ProjectTox-Core/libtoxcore.pc.in

@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libtoxcore
+Description: Tox protocol library
+Requires:
+Version: @PACKAGE_VERSION@
+Libs: @NACL_OBJECTS_PKGCONFIG@ -L${libdir} @NACL_LDFLAGS@ -ltoxdns -ltoxencryptsave -ltoxcore @NACL_LIBS@ @LIBS@ @MATH_LDFLAGS@
+Cflags: -I${includedir}

data/ProjectTox-Core/m4/ax_have_epoll.m4

@@ -0,0 +1,104 @@
+# ===========================================================================
+#       http://www.gnu.org/software/autoconf-archive/ax_have_epoll.html
+# ===========================================================================
+#
+# SYNOPSIS
+#
+#   AX_HAVE_EPOLL([ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
+#   AX_HAVE_EPOLL_PWAIT([ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
+#
+# DESCRIPTION
+#
+#   This macro determines whether the system supports the epoll I/O event
+#   interface. A neat usage example would be:
+#
+#     AX_HAVE_EPOLL(
+#       [AX_CONFIG_FEATURE_ENABLE(epoll)],
+#       [AX_CONFIG_FEATURE_DISABLE(epoll)])
+#     AX_CONFIG_FEATURE(
+#       [epoll], [This platform supports epoll(7)],
+#       [HAVE_EPOLL], [This platform supports epoll(7).])
+#
+#   The epoll interface was added to the Linux kernel in version 2.5.45, and
+#   the macro verifies that a kernel newer than this is installed. This
+#   check is somewhat unreliable if <linux/version.h> doesn't match the
+#   running kernel, but it is necessary regardless, because glibc comes with
+#   stubs for the epoll_create(), epoll_wait(), etc. that allow programs to
+#   compile and link even if the kernel is too old; the problem would then
+#   be detected only at runtime.
+#
+#   Linux kernel version 2.6.19 adds the epoll_pwait() call in addition to
+#   epoll_wait(). The availability of that function can be tested with the
+#   second macro. Generally speaking, it is safe to assume that
+#   AX_HAVE_EPOLL would succeed if AX_HAVE_EPOLL_PWAIT has, but not the
+#   other way round.
+#
+# LICENSE
+#
+#   Copyright (c) 2008 Peter Simons <simons@cryp.to>
+#
+#   Copying and distribution of this file, with or without modification, are
+#   permitted in any medium without royalty provided the copyright notice
+#   and this notice are preserved. This file is offered as-is, without any
+#   warranty.
+
+#serial 10
+
+AC_DEFUN([AX_HAVE_EPOLL], [dnl
+  ax_have_epoll_cppflags="${CPPFLAGS}"
+  AC_CHECK_HEADER([linux/version.h], [CPPFLAGS="${CPPFLAGS} -DHAVE_LINUX_VERSION_H"])
+  AC_MSG_CHECKING([for Linux epoll(7) interface])
+  AC_CACHE_VAL([ax_cv_have_epoll], [dnl
+    AC_LINK_IFELSE([dnl
+      AC_LANG_PROGRAM([dnl
+#include <sys/epoll.h>
+#ifdef HAVE_LINUX_VERSION_H
+#  include <linux/version.h>
+#  if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,45)
+#    error linux kernel version is too old to have epoll
+#  endif
+#endif
+], [dnl
+int fd, rc;
+struct epoll_event ev;
+fd = epoll_create(128);
+rc = epoll_wait(fd, &ev, 1, 0);])],
+      [ax_cv_have_epoll=yes],
+      [ax_cv_have_epoll=no])])
+  CPPFLAGS="${ax_have_epoll_cppflags}"
+  AS_IF([test "${ax_cv_have_epoll}" = "yes"],
+    [AC_MSG_RESULT([yes])
+$1],[AC_MSG_RESULT([no])
+$2])
+])dnl
+
+AC_DEFUN([AX_HAVE_EPOLL_PWAIT], [dnl
+  ax_have_epoll_cppflags="${CPPFLAGS}"
+  AC_CHECK_HEADER([linux/version.h],
+    [CPPFLAGS="${CPPFLAGS} -DHAVE_LINUX_VERSION_H"])
+  AC_MSG_CHECKING([for Linux epoll(7) interface with signals extension])
+  AC_CACHE_VAL([ax_cv_have_epoll_pwait], [dnl
+    AC_LINK_IFELSE([dnl
+      AC_LANG_PROGRAM([dnl
+#ifdef HAVE_LINUX_VERSION_H
+#  include <linux/version.h>
+#  if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19)
+#    error linux kernel version is too old to have epoll_pwait
+#  endif
+#endif
+#include <sys/epoll.h>
+#include <signal.h>
+], [dnl
+int fd, rc;
+struct epoll_event ev;
+fd = epoll_create(128);
+rc = epoll_wait(fd, &ev, 1, 0);
+rc = epoll_pwait(fd, &ev, 1, 0, (sigset_t const *)(0));])],
+      [ax_cv_have_epoll_pwait=yes],
+      [ax_cv_have_epoll_pwait=no])])
+  CPPFLAGS="${ax_have_epoll_cppflags}"
+  AS_IF([test "${ax_cv_have_epoll_pwait}" = "yes"],
+    [AC_MSG_RESULT([yes])
+$1],[AC_MSG_RESULT([no])
+$2])
+])dnl