search

otrv4 / libotr-ng-toolkit

2 stars 1 forks source link

Implement parsing #1

Open claucece opened 6 years ago

claucece commented 6 years ago

Description:

OTR_parse should provide a program (command) the shows in a easier-to-read way the OTRv4 messages. Also need to provide functions that will be used by the other functions of toolkit.

Parser should be able to parse:

Reference: https://bugs.otr.im/lib/libotr/blob/master/README (TOOLKIT section) https://bugs.otr.im/lib/libotr/tree/master/toolkit https://github.com/otrv4/otrv4/blob/master/otrv4.md#forging-transcripts

annacruz commented 6 years ago

This issue includes to make public some fuctions of libotr

deniscostadsc commented 6 years ago

@annacruz and me had a quick conversation and we have decided to implement the non-interactive messages later. We'll keep this issue close until we implement them.

claucece commented 6 years ago

ok @deniscostadsc Quick question: why only the parsing of the data message takes a pointer and why there are no testing of the other messages?

claucece commented 6 years ago

I also see a lot of potential memory leaks on the implemented functionality, so it will be nice to add tests to check these kind of things.

claucece commented 6 years ago

Parsing is using a bunch of printfs that are not global, as it depends on the os:

https://github.com/otrv4/libotr-ng-toolkit/commit/edf63a2cb4c354ddf5f620b460aa818924c18971

Parsing should not do that.

claucece commented 6 years ago

Almost all parsing functions are memory leaking, see:

==14089== 408 (24 direct, 384 indirect) bytes in 1 blocks are definitely lost in loss record 41 of 47
==14089==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14089==    by 0x514F2B4: _gcry_xmalloc (global.c:914)
==14089==    by 0x5218C0E: _gcry_mpi_alloc (mpiutil.c:84)
==14089==    by 0x5215E56: _gcry_mpi_scan (mpicoder.c:519)
==14089==    by 0x514B545: gcry_mpi_scan (visibility.c:357)
==14089==    by 0x5681A2C: otrng_dh_mpi_deserialize (dh.c:236)
==14089==    by 0x5680EF6: otrng_deserialize_dh_mpi_otr (deserialize.c:152)
==14089==    by 0x567E286: otrng_dake_identity_message_deserialize (dake.c:186)
==14089==    by 0x4015E0: otrng_toolkit_test_parse_identity_message (decode.c:43)
==14089==    by 0x4EA3A80: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==14089==    by 0x4EA3C45: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==14089==    by 0x4EA3F9A: g_test_run_suite (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==14089==
claucece commented 6 years ago

I'll try to fix the mem leaks :)

claucece commented 6 years ago

So, it is only missing the prekey message. But for this, we need the whole DAKE-3 message, and probably the others server DAKE messages.