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.

Sign up for GitHub

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

Jump to bottom

Check how errors are shown #36

Closed
claucece opened this issue Aug 13, 2018 · 13 comments
Closed

Check how errors are shown #36

claucece opened this issue Aug 13, 2018 · 13 comments
Assignees
@pedropalau
Labels
importance medium An issue that is medium level importance. It's good to have but not 100% necessary. UI

Comments

@claucece
Copy link
Member

Check the text shown to the user.
@claucece claucece added importance medium An issue that is medium level importance. It's good to have but not 100% necessary. UI labels Aug 13, 2018
@claucece
Copy link
Member Author

@sahrosa

@claucece
Copy link
Member Author

claucece commented Oct 5, 2018

Now that errors are actually handled by the plugin; we can recheck its information.

@olabini
Copy link
Contributor

olabini commented Mar 10, 2019

We should just check that the text is proper and correct?

@claucece
Copy link
Member Author

Manly that when the error occurs, the error message is shown and it is the correct one. @olabini

@olabini
Copy link
Contributor

olabini commented Mar 11, 2019

OK, make sense.

@claucece
Copy link
Member Author

These are the error messages: https://github.com/otrv4/otrv4/blob/master/otrv4.md#otr-error-messages


@claucece
Copy link
Member Author

@peterpalau This are the error messages:

  ERROR_1: (the message is undecryptable)
    Unreadable message
  ERROR_2: (the message arrived in a state that is not encrypted messages)
    Not in private state message
  ERROR_3: (the instance tags do not correspond)
    Malformed message

You can find the first one here:
https://github.com/otrv4/libotr-ng/blob/master/src/otrng.c#L1997 , when the flag is not set.

You can find the second one here:
https://github.com/otrv4/libotr-ng/blob/master/src/otrng.c#L2084, when the state is incorrect.

You can find the third one like here: https://github.com/otrv4/libotr-ng/blob/master/src/otrng.c#L1285, when the instance tags do not correspond.

@claucece
Copy link
Member Author

The way error messages work is like this:

Alice sends a data message which has some kind of error. Bob receives it but instead of displaying it to the user, it sends an error message saying "hey your message had an error". Alice receives this error message and it gets displayed to her. You can see how they work here: https://github.com/otrv4/libotr-ng/blob/master/src/test/functionals/test_api.c#L568

@pedropalau
Copy link
Member

@claucece Maybe you know what about this error in libotr-ng?

pidgin: client.c:827: otrng_client_get_client_profile: Assertion `client->client_profile != NULL' failed.
Aborted (core dumped)

I know that when the assertion condition is false write out the result to stderr and then execute abort.

But why client->profile is NULL when client not.

@pedropalau
Copy link
Member

I found the reason or maybe how to solve this, is setting write/read permissions to the prekey-server-docker-compose folder.

@claucece
Copy link
Member Author

Hey @peterpalau ! I guess you solved it ;) Let me know if it still persists ;)

@pedropalau
Copy link
Member

pedropalau commented Jun 19, 2019 •
edited
Loading

@claucece this is interesting.

If Alice send an unreadable message to Bob, which one is supposed to receive the following message?

You transmitted an unreadable message.

Even forcing the library to show the error OTRNG_ERROR_UNREADABLE_EVENT, this message appear to Bob when Alice is which wrote the message, and also this only occurs when the first message is sent, after that, Alice and Bob can continue writing each other normally.

I'm missing something?

@claucece
Copy link
Member Author

claucece commented Jun 20, 2019 •
edited
Loading

hey @peterpalau !

If Alice send an unreadable message to Bob, which one is supposed to receive the following message?

Alice. I have just tested and it shows up to Alice. See:

Sending (ssl) (alice@localhost/qb7N_w0s): <message type='chat' id='purplec801db87' to='bob@localhost'><active xmlns='http://jabber.org/protocol/chatstates'/><body>?OTR:AAQ126FP8QAAAAAAAAAFAAHboU/xAAIAEFpJyfW2AO87NHchqvYaPXx9leDN0wBEcryOEFO7wAtJoBhb4OtRXTtM2Bllx1PIhnMmwUtcy6rGAAADABJPZ0vY7kb8Ei4zTNwuBr7iN58Y/uWuilv8YDWv/95slD/WySN5yLaui5kn4AZjwI733lkKG/09cAAABAAAAAIzNAAFAAAAAF0M6AzCwZafB/62snJUsiWFp/VpNEuB80Z0XfbWdToA7dufaekcmEeyi4+kdGX3N6wXYjYmRQAjmZrr3gDs+rkfxsmybwLKo6SDitflMldXKVVi1VWwjmXtWP81pQsVPz56MG7oLrWVTrZ6HuBRAMquNALIIgA8gr//TccFgq5K5zS9JrsVhIwUGwBKG2BpsOpvPAPigbIIdY9Kza+cjuu3bN/wWETDglXPzAzenAAAAAGAeUl8P7pA/immbaf8gfB48dO/O11SH5uU/WRu2hRowVYG/Sn2eCiSbD14zBtEZe/VlZCov/JqLkdxCBcgLriyKsLLldNzN/FP4TjD7ZyjnM5yjk/yLC6rug+ShkjDHXM8aAE17iYbxuksxymmVI2Icwk64mtgKnZdfEsUOA7eneaQ0ZlDAhMlDiqflZrNAEAyhASKu8m+I7dRgNfmDz14RFBbCdW28Ak/97SCxHGsreVuHejXOVPH1ZVvtnaKlhkLo1y759r0NJTHMg1OWLo41ZQoegGUEphCHt9j3meBT9X8IuUtLQ32MLUrAEavvIWl9oc2mEDtEGS88uOXsYGfYauZPBYlapwbyqeD9wpvjqxnjWOm36rFbAZRmG9QdrvV3k73E8Fj/Q+yJb8ds+fcL5wCjNDWkl/38MKWKNEGROElVk/13FRAmglBz+PTokHIANZm/VCjtHL99DYYXih+d+mGh4P45Dzkdd2RyNvpRU0w0iTuHKywPbhRJK9m/NoI.</body></message>

(16:42:10) jabber: Recv (ssl)(210): <message to='alice@localhost' from='bob@localhost/3EI0rlcx' id='purpledb3ccb39' type='chat'><active xmlns='http://jabber.org/protocol/chatstates'/><body>?OTR Error: ERROR_3: OTRNG_ERR_MALFORMED</body></message>

Alice and Bob can continue writing each other normally.

Yeah, they should. Only one message is malformed. It does not mean that the rest will be.

pedropalau added a commit that referenced this issue Jun 20, 2019
@pedropalau
Improve error messages
83fd650 
- This commit improve the texts of the error messages.
- This refer to issue #36
pedropalau added a commit that referenced this issue Jun 20, 2019
@pedropalau
Fix an error in the message
f3fcbc1 
- The unreadable message error should be shown to the person receiving the message
- This is related to #36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pedropalau pedropalau

Labels
importance medium An issue that is medium level importance. It's good to have but not 100% necessary. UI
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@olabini @MauroVelasco @claucece @pedropalau @Cris2760