mirror of https://github.com/profanity-im/profanity.git synced 2024-06-09 21:30:42 +00:00
Commit Graph

5521 Commits

Author SHA1 Message Date
Michael Vetter
5490d148b9 Add my GitHub Sponsors URL 2019-11-05 17:36:05 +01:00
Michael Vetter
ba0f925222 Fix add_history usage in down arrow handler
[Programming with GNU
History](http://www.math.utah.edu/docs/info/hist_2.html) mentions

Chet, maintainer of readline told me about it. (Thanks Chet!)

Seems like we need to call this so that the history offset is at the
right end of the list. I assume it's called in the linehandler

Fix https://github.com/profanity-im/profanity/issues/200
2019-11-05 17:19:51 +01:00
Michael Vetter
330ef3bcf3 Store current input line in history
Regards https://github.com/profanity-im/profanity/issues/200

This doesn't work yet. And I have no idea why.
Weird behaviour:

- start profanity
- type 'ASDF'
- ctrl+arrow down
-> text vanishes (like intended)
- arrow up
-> nothing happens (intended is that the last history item [ASDF]

- type 'ABC'
- press enter
- arrow up
-> ABC appears
- enter

- type 'UUU'
- ctrl+arrow down
- type 'ZZZ'
- enter
- arrow up
- ZZZ appears
- arrow up
- UUU appears

So in the latter case we added to history and deleted from the input
line and then immediately entered new text and pressed enter, to add
this to the history too.
When we do this the not sent text succesfully was stored in history.
2019-11-05 17:18:42 +01:00
Michael Vetter
643d12af44 Move tls show to titlebar command
Previously we had `/tls show on|off` to manipulate the UI setting for
the title bar. To decide whether to show TLS info there or not.

This should go into `/titlebar`.

Now we have `/titlebar show|hide tls` for this.

Regards https://github.com/profanity-im/profanity/issues/1116
2019-11-05 13:48:26 +01:00
Michael Vetter
8d2b1b05e7 Initialize ProfBufEntry->id correctly 2019-11-01 18:31:19 +01:00
Michael Vetter
bc282ef569 Move id from DeliveryReceipt to ProfBuffEntry struct
XEP-0184: Message Delivery Receipts, *requires* the id attribute.
Generally this is not the case.
For this reason the id was only present in the DeliveryReceipt struct
since it was only used for XEP-0184.

For https://github.com/profanity-im/profanity/issues/660 XEP-0313 MAM
and https://github.com/profanity-im/profanity/issues/805 XEP-0308 Last Message Correction
we will also need the id.

So in preparation for further work let's move the id to the general

We will need to adapt code so that we actually always write the ID if we
receive one.
2019-11-01 17:53:59 +01:00
Michael Vetter
d5212d8593 Remove not needed if blocks 2019-11-01 17:35:17 +01:00
Michael Vetter
f71de61b9d Don't override ProfMessage Id with origin-id
Profanity sends the same value for both. Other clients might not.
Safe both since we could need them later.

Once we implement Last Message Correction we will need the regular id.
If we override it with origin-id and another client chooses to not use
the same value for id and origin-id then we can't interpret the id sent
with the LMC request correctly.
2019-10-31 13:45:44 +01:00
Michael Vetter
4ecd4dea6a Replace sent_messages list with algo
For OMEMO we had a list with our sent messages.
It was used so that we don't decrypt our own messages in MUCs that come
in via reflection.

Recently for https://github.com/profanity-im/profanity/pull/1209 we
started to use origin-id and use an algorithm so we can detect our own
sent messages via checking origin-id.

Profanity uses the same id for the message ID and origin-id.

With 06f300a42c we added the
message_is_sent_by_us() function.

We implemented XEP-0359 this way to fix
https://github.com/profanity-im/profanity/issues/1201 so that we don't
log our own messages in MUCs twice.

We can now check whether the message was sent by us using this function
and can get rid of the list.

Probably we could also put many parts of the sv_ev_room_message()
function inside (else) part of `if (!(g_strcmp0(mynick,
message->jid->resourcepart) == 0 && message_is_sent_by_us(message))) {`.

Have to look more closely whether any of this needs to be run in case
the message actually comes from us.
2019-10-31 12:56:48 +01:00
Michael Vetter
Merge pull request #1217 from aszlig/omemo-check-element-names
omemo: Check stanza names when iterating nodes
2019-10-30 18:36:33 +01:00
omemo: Check stanza names when iterating nodes
Some clients (eg. PSI) are sending the stanzas delimited by whitespace
text nodes, which will fail while looping through the <prekeys/>
children and also print weird errors when iterating through the <list/>
of devices.

When debugging this, I was looking at the XML of Gajim and PSI and first
was somehow confused why Profanity printed "OMEMO: received device
without ID" while the XML looked identical (minus the actual IDs and the
JIDs of course).

However, Gajim was sending the XML without whitespace nodes in between
and PSI did not, so for example the following (with the relevant
whitespace nodes marked with X):

  <message type="headline" to="..." from="...">
    <event xmlns="http://jabber.org/protocol/pubsub#event">
      <items type="headline" node="eu.siacs.conversations.axolotl.devicelist">
        <item id="...">
          <list xmlns="eu.siacs.conversations.axolotl">
          X <device id="..."/>
          X <device id="..."/> X
    <delay xmlns="urn:xmpp:delay" stamp="..." from="..."/>

... would result in three times the "OMEMO: received device without ID"
error, because we actually have three XML text nodes here that obviously
don't have an "id" attribute.

Now since the <list/> children above aren't really a problem and only
annoying, text nodes in the <prekeys/> stanza actually cause
omemo_start_device_session_handle_bundle to return failure.

I've fixed this by explicitly matching the stanza names we are
interested in, skipping everything else.

Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @devhell
2019-10-29 23:10:07 +01:00
Michael Vetter
900426025e Put ifdef around tray.h functions
Only define in case we built with GTK support.
2019-10-29 21:03:39 +01:00
Michael Vetter
f5afedd171 Remove not neede gtk_init() in tray.c
gtk_init_check() already has that functionality.
2019-10-29 21:00:56 +01:00
Michael Vetter
81253cd2ca Remove comments 2019-10-29 20:59:54 +01:00
Michael Vetter
Merge pull request #1216 from profanity-im/feature/issue-156-clipboard
Paste command
2019-10-29 15:21:43 +01:00
Michael Vetter
5d6cb3c741 Dont use clipboard_init yet
For now we initialize gtk in tray_init().
Should maybe use a general function and check in tray_init and
clipboard_init whether gtk was already initialized.
2019-10-29 15:20:57 +01:00
Michael Vetter
291f9de1e9 Send clipboard via /paste
New command `/paste` that sends the clipboard in MUC, Chat etc windows.

Fix https://github.com/profanity-im/profanity/issues/156
2019-10-29 15:20:57 +01:00
Michael Vetter
900a0451a7 Adjust tray configure switch to also include clipboard
General GTK.
2019-10-29 15:20:57 +01:00
Michael Vetter
b46dbcc363 Add clipboard feature
Use GTK to take the text from the clipboard.
Add `/paste` command which pastes this text now to console window.
2019-10-29 15:20:57 +01:00
Michael Vetter
aa0c638394 Update chat_log_pgp_msg_out() usage
Fix build
2019-10-29 15:20:24 +01:00
Michael Vetter
6bfdc5422c Adjust message stubs in unit tests 2019-10-29 11:55:27 +01:00
Michael Vetter
5a0a6c97e2 Two carbon logging changes
Add resourcepart to the outgoing carbon that is logged, so we use the
correct filenames for MUC PMs.

Dont log incoming carbons of MUC PMs as a workaround to faulty server

See https://wiki.xmpp.org/web/Multi-Session_Nicks#Private_Messages under
'Client-side workaround behavior'.

Regards https://github.com/profanity-im/profanity/issues/1214
2019-10-29 11:46:01 +01:00
Michael Vetter
9788410aaf Also log sv_ev_delayed_private_message 2019-10-29 10:52:11 +01:00
Michael Vetter
7dd747b58d Set mucuser in carbon case
Also we initialize mucuser properly.

Now in case of a carbon of a MUC PM we sv_ev_incoming_carbon() which
calls _sv_ev_incoming_plain() and then we log it via chat_log_msg_in()
in there.
But we also get the sv_ev_incoming_private_message() and call
chat_log_msg_in() in there too. So the incoming message get's logged
2019-10-29 10:41:07 +01:00
Michael Vetter
8c8c18c6fd Actually log MUC PM messages
If I'm not mistaken MUC PMs have not been logged at all if there was no
other client sending carbons.
This should add MUC PM logging functionality.

We still need to make sure carbons log to the same file.

Regards https://github.com/profanity-im/profanity/issues/1214
2019-10-28 23:36:42 +01:00
Michael Vetter
f186eb94da Remove not neede free
It's in the def == NULL case. So will always be noop.
2019-10-25 14:06:03 +02:00
Michael Vetter
6a88af6bc6 Remove /leave command
We have `/close` which does the same and more.

Regards https://github.com/profanity-im/profanity/issues/1116
2019-10-22 15:33:54 +02:00
Michael Vetter
47d8d210ab Make forest theme more readable 2019-10-22 15:10:55 +02:00
Michael Vetter
8764e59650 Adjust stub for connection_get_profanity_identifier 2019-10-22 14:24:07 +02:00
Michael Vetter
22bf281399 Make prof_identifier const 2019-10-22 12:47:32 +02:00
Michael Vetter
6b75848f96 Display ownership of connection_get_profanity_identifier 2019-10-22 12:04:16 +02:00
Michael Vetter
f023eb8d72 Dont allow new issues 2019-10-22 11:13:41 +02:00
Michael Vetter
ba18752405 Use UUID in origin-id and id
Let's use UUID to have a more random string then just 10 alphanumeric
2019-10-22 11:10:37 +02:00
b16426f66d Change default text colors to default (#1213)
Change default themes text color

Using "default" instead of white makes the default better readable
when using a black/dark font on white/light background.

May fix #535
2019-10-22 08:13:39 +02:00
Michael Vetter
2292f15633 Make sure date vars are initialized 2019-10-21 16:19:35 +02:00
Michael Vetter
40d9dcae87 Properly display chatwin history
So far if one had enabled `/history` and did `/msg somenick` the history
was loaded from file and displayed like this:

04-04-17 15:23 - 3/4/2017:
01-01-00 10:30 - me: ....
01-01-00 10:31 - somebody: ....
01-01-00 10:32 - somebody: ....

So the first line contained the actual date. But the date used in each
line was always 01-01-2000. This date was for some reason hardcoded.

This commit now actually uses that date to build the proper GDateTime
instead of just printing it.

Fix https://github.com/profanity-im/profanity/issues/922
2019-10-21 15:26:40 +02:00
Michael Vetter
ef19b45e64 Remove old comment
It's not up to date.
Some time ago we changed from individual handlers to general ones.
2019-10-21 10:28:29 +02:00
Michael Vetter
Merge pull request #1209 from jubalh/feature/xep-0359
2019-10-21 09:56:15 +02:00
Michael Vetter
963ab841b4 Set prof_ident to NULL after free
This caused the bug mentioned in the PR comment:

It seems with the changes done here we get a crash in: src/xmpp/message.c message_handlers_init() when looking up handlers: ProfMessageHandler *handler = g_hash_table_lookup(pubsub_event_handlers, curr->data);.

Steps to reproduce:

    open Profanity and connect
    /autoping set 10
    /autoping timeout 10
    stop WiFi/connection
    wait for Lost connection
    restart wifi
2019-10-21 09:50:13 +02:00
Michael Vetter
8a5932b251 Rename _calculate_identifier to _compute_identifier 2019-10-20 00:01:19 +02:00
Michael Vetter
db4b55eee0 Rename random_bytes to profanity_instance_id 2019-10-19 23:27:19 +02:00
Michael Vetter
31014b5e51 Fix which message we want to log 2019-10-19 23:24:33 +02:00
Michael Vetter
2a4d1b8410 Free hmac and msgid 2019-10-19 08:18:37 +02:00
Michael Vetter
f190d2c5f2 Free prof_identifier in case of reconnect
Bedore we assign it new.
2019-10-19 07:40:59 +02:00
Michael Vetter
c3912df05b Move ProfMessage and message_is_sent_by_us to xmpp
Not meant for internal usage only.
2019-10-19 06:36:47 +02:00
Michael Vetter
4d7a496ae2 Change origin-id/id algo
Hash twice.
Use HMAC SHA256 from glib.
2019-10-18 16:12:26 +02:00
Michael Vetter
72bdae1014 Add message_is_sent_by_us stub 2019-10-18 14:53:06 +02:00
Michael Vetter
06f300a42c Move message sent by us logic in own function 2019-10-18 14:50:25 +02:00
Michael Vetter
3bd5c9f535 Remove accidentally added file 2019-10-18 12:24:34 +02:00
Michael Vetter
dfead6415f sv_ev_room_message: log in all cases if not our client
Forgot to check what happens if the length is <= 10.
2019-10-18 11:59:39 +02:00