Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement parsing #1

Open
9 of 10 tasks
claucece opened this issue Nov 26, 2017 · 8 comments
Open
9 of 10 tasks

Implement parsing #1

claucece opened this issue Nov 26, 2017 · 8 comments

Comments

@claucece
Copy link
Member

claucece commented Nov 26, 2017

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
Copy link
Contributor

This issue includes to make public some fuctions of libotr

@annacruz annacruz added the 3 label Jul 19, 2018
@claucece claucece changed the title Finish implementing OTR_parse Finish implementing parsing Jul 23, 2018
@annacruz annacruz changed the title Finish implementing parsing Implement parsing Jul 23, 2018
@deniscostadsc
Copy link
Contributor

@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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

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

edf63a2

Parsing should not do that.

@claucece
Copy link
Member Author

claucece commented Jul 30, 2018

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
Copy link
Member Author

I'll try to fix the mem leaks :)

@claucece
Copy link
Member Author

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.

@claucece claucece removed the 3 label Aug 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants