Compiling on Windows

[EionRobb]

There's a few errors when compiling on Windows:

There's no strnlen() function, workaround is

#ifdef _WIN32
#define strnlen(a, b) (MIN(strlen(a), (b)))
#endif

g_hash_table_add() doesn't exist until too-new a version of glib. Workaround is to use g_hash_table_replace(qmsg_p->sess_handled_p, addr_key, addr_key); in lurch_bundle_request_cb() instead.

lurch_addr_list_destroy_func() won't compile because you're freeing a const char in free(addr_p->name);

[gkdr]

I fixed these things in 6c246bbe72999448b301966d7ffd1d2b421d0e9d. If you have time to try again I'd be glad to hear the result!

[dreamflasher]

@EionRobb Which compiler and which shell do you use on windows for compiling? (I am asking because neither cygwin nor mingw worked for me)

[EionRobb]

@gkdr Getting a few more errors in libomemo/src/libomemo.c since there's no strdup(), strndup() or strsep(). Replacing the first two with g_strdup() and g_strndup() is simple enough, but I'm not sure about strsep() - can that be replaced with strtok()?

g_list_copy_deep() is also in too-new a glib for what's used on Windows (2.28)

@DreamFlasher I'm hand-crafting new Makefile's in a similar fashion to the Makefile.mingw's that ship with Pidgin

[EionRobb]

I've got it to compile, but it just says "Failed to access axc db." when running the /lurch command

My build env is at http://eion.robbmob.com/lurch

[gkdr]

I looked in the 2.28.7 glib docs and g_strsplit() seems available, so I will use that. Replacing g_list_copy_deep() should not be that hard, I had to write the copy function myself already anyway.

The DB error is probably an issue with the path - to get that, I concatenate the output of purple_user_dir(), "/", the account name, and a fixed string. This might not work in Windows - if I remember correctly it uses "\" as path separators? In any case you can probably see the issue if you look in the purple user dir.

I have another question: sem_init() just worked? Do you happen to know if sem_open() would work just as well?

[gkdr]

The suggested replacements were done in cb081fd6a9509a2fcd23b61f6f31ed38324b3505, I also make it output the DB path it is looking for. Can you tell me if it looks wrong?

[aladar42]

I'm not sure if it's OT in this thread, but I didn't want to open a new issue - I tried installing the plugin on Windows, both from EionRobb's link above and from my own build (on Linux), but it just won't show up in the plugins tab in Pidgin, does anyone know what can be wrong? It works just fine on Linux.

[gkdr]

If you open the debug window (Tools->Debug Window) and then open the plugins window, it should tell you the results of probing the plugins (it should be at the very top somewhere). Maybe that will give us some more information on what is happening.

[aladar42]

(15:29:45) plugins: probing C:\Program Files (x86)\Pidgin\plugins\lurch.dll (15:29:45) plugins: C:\Program Files (x86)\Pidgin\plugins\lurch.dll is not loadable: `C:\Program Files (x86)\Pidgin\plugins\lurch.dll': The specified module could not be found.

[gkdr]

I'm sorry, I couldn't find anything on this. Are you sure you have all the dependencies installed? Specifically, I use POSIX semaphores which Windows does not support natively, but there is a lib for that which I think is used by EionRobb.

[aladar42]

I'll take a look tomorrow. Would you be able to cross compile the library yourself? It would be immensely helpful as I'm trying to recommend Pidgin to my friends and I can't seem to be able to cross compile or myself.

[EionRobb]

@aladar42 You're probably missing the pthreadGC2.dll that needs to go into the Program Files (x86)\Pidgin folder (not the plugins subfolder)

@gkdr It would be great if it didn't need pthreads as a dependency, especially since libpurple is non-thread-safe

[gkdr]

I am only using semaphores, not threads. And libpurple does use threads to handle outgoing and incoming messages, right? At least gdb shows a lot of thread creation when I send a message, and I need to synchronize some of that. libaxolotl/libsignal needs semaphores too. I can probably try to rewrite it to use native semaphores, I'll look into it.

[aladar42]

Is there any way to cross compile it for windows, then? I'd like to help test too and I have a few people who'd like to use Pidgin with omemo. I tried dockcross and mxe with no luck.

[gkdr]

Well, EionRobb gets it to run, so I would assume so! You don't need the dll for compiling, but I don't know how Windows deals with shared libraries, so I can't tell you where to put the pthreadGC2.dll. Not sure if it's the same, but I've read about "phtreads-w32", maybe you can find some more info if you search for that. (Even though it runs, there is currently the issue that it cannot find the DB path, but it seems EionRobb did not have time to look at it again after I added some more debug output.)

[dreamflasher]

@EionRobb would you be so kind to share your compiled dlls with us as soon as it is working? :)

[aladar42]

Well, I was hoping someone would have an advice on how to cross compile it on Linux (for Windows), becuase I don't have enough code experience to rebuild the makefile as EionRobb did. I tried dockcross, but it fails to find sqlite3, and I have no idea what other methods of cross compiling Linux has.

[EionRobb]

With the latest changes, axc and libomemo are compiling without modifications. I can't get lurch.c to compile though because it can't find sem_open(). Should this be defined in axc somewhere?

Edit: whoops, its not that it can't find it, must be something with the paremeters, the exact error is

src/lurch.c:130:11: error: assignment makes pointer from integer without a cast [-Werror]

Edit2: mingw has a different header for sem_open than the man page says:

PTW32_DLLPORT int __cdecl sem_open (const char * name,
                int oflag,
                mode_t mode,
                unsigned int value);

Another option might be using glib functions rather than posix functions for semaphores (eg with http://stackoverflow.com/questions/10711258/implement-a-semaphore ) so as to not need the pthread dependency?

[gkdr]

As discussed in IRC, I will remove semaphores from the code as apparently libpurple does not use threads (previously I thought the asynchronous requests would require some synchronizing). This should resolve some more issues.

Edit: Currently I already commented the code out on the "nosem" branch, but axc still uses them in a different form.

[EionRobb]

The dll at https://eion.robbmob.com/lurch/lurch.dll is using the nosem branch, with some additional modifications to not use pthreads, so the pthreadGC2.dll is no longer needed in the Pidgin folder.

Tested and working well (just have to remember to reconnect to any XMPP account that wants to use it after enabling the plugin) 😃

[aladar42]

Still not working at all here.

(22:13:31) plugins: probing C:\Program Files (x86)\Pidgin\plugins\lurch.dll (22:13:31) plugins: C:\Program Files (x86)\Pidgin\plugins\lurch.dll is not loadable: `C:\Program Files (x86)\Pidgin\plugins\lurch.dll': %1 is not a valid Win32 application.

Pidgin 2.11.0 (libpurple 2.11.0)

[EionRobb]

Oops, it'll still need libgcrypt-20.dll and libgpg-error-0.dll in the Program Files\Pidgin folder (not the plugins subfolder), (I forgot that I have those dll's already from the Telegram and LINE plugins and that other people probably won't). I've added those dll's into https://eion.robbmob.com/lurch to download

"%1 is not a valid Win32 application" might be displayed if your virus checker is blocking the file? Normally it should say "The specified module could not be found" if there's a missing dll :/

I'll have a play around with making an exe installer to make it easier to install

[dreamflasher]

Thank you @EionRobb! For me the plugin is detected correctly and I can use the /lurch commands. Unfortunately, the fingerprint is not announced correctly and it doesn't receive the fingerprints of my contact. So when I write from lurch the other person using conversations sees You received an OMEMO encrypted message, but your client does not support it. (but the Omemo option is correctly been selected in conversations). On the other hand, messages sent from conversations don't reach pidgin/lurch (while they are received at a Gajim instance).

[gkdr]

Do you see anything on the debug log? It sounds like a more general parsing issue, sending messages to and receiving from Gajim and Conversations definitely works for me though (on Linux). If Conversations let you select OMEMO, then the key/device data must have been already announced correctly.

I couldn't exactly tell from your wording, but the receiving issues might be that libpurple does not support Message Carbons - you'll only receive the message at one messenger (which in my experience usually is not Pidgin).

Edit: I should note that the message you see is always sent with encrypted messages by this plugin, so that the recipient gets some kind of notification if anything goes wrong (so your client does encrypt a message). It should be removed after decryption, and is for me, so it looks like there is an issue with the session. Again, do the messages in the debug log look correct? Pidgin displays all sent messages there, and you can check if it contains the device ID of your contact.

[gkdr]

The semaphore code is now (892d96bf6ef73bb6c06e86a0a05a0e30d92b6fb7) removed in the master branch, I also added a compile-time setting to remove the semaphore code from axc. -> No pthread dependency, run- or compile-time.

[dreamflasher]

@gkdr How do I obtain the debug log? Well I had established a chat with that contact before, so that's why Omemo is enabled in conversations. So the setup is as follows: Previously conversations <-> Gajim, Now {conversations, Gajim, lurch). The lurch fingerprint does not appear in Gajim or conversations list of fingerprints. Oh and I get the "You received an Omemo encrypted message..." twice per message.

[gkdr]

@DreamFlasher In Pidgin, go to Help->Debug Window. Sending (and then receiving) of a message looks like that for me, including the Jabber debug output I'm interested in:

(16:21:29) lurch: retrieved devicelist for a@localhost:
<publish node="eu.siacs.conversations.axolotl.devicelist"><item><list
xmlns="eu.siacs.conversations.axolotl"><device id="1541717762" /></list></item></publish>

(16:21:29) lurch: retrieved own devicelist:
<publish node="eu.siacs.conversations.axolotl.devicelist"><item><list
xmlns="eu.siacs.conversations.axolotl"><device id="1395287578" /></list></item></publish>

(16:21:29) lurch: lurch_msg_encrypt_for_addrs: trying to encrypt key for 1 devices
(16:21:29) lurch: lurch_key_encrypt: encrypting key for a@localhost:1541717762
(16:21:29) xmlnode: XML parser error for xmlnode 0x25e38a0: Domain 3, code 100, level 1: xmlns: URI eu.siacs.conversations.axolotl is not absolute
(16:21:29) jabber: Sending (ssl) (b@localhost/e86e220a-0df5-4986-81f4-bc4522fc04c8): <message type='chat' id='purple9db5141a' to='a@localhost'><active xmlns='http://jabber.org/protocol/chatstates'/><body>You received an OMEMO encrypted message, but your client does not support it.</body><encrypted xmlns='eu.siacs.conversations.axolotl'><header sid='1395287578'><key rid='1541717762'>MwohBQzkOGIo4sepqLZz/v9IdUJxAL5YCt4vzyKuKmdmsYlTEAYYAiIgxnf3nNB7cfASwVv0QqKk9j0Q1mgsOc3S78asn+U9cXnFE9SGlcjGWQ==</key><iv>+4Hi2XCCbh/agWfM/pgxKw==</iv></header><payload>YUFj+Ub0VK5CqOssN3dQ7Bu9</payload></encrypted><store xmlns='urn:xmpp:hints'/></message>
(16:21:29) jabber: Sending (ssl) (b@localhost/e86e220a-0df5-4986-81f4-bc4522fc04c8): <message type='chat' id='purple9db5141b' to='a@localhost'><active xmlns='http://jabber.org/protocol/chatstates'/></message>
(16:21:29) jabber: Recv (ssl)(612): <message id='purple9db5141a' type='chat' to='a@localhost' from='b@localhost/e86e220a-0df5-4986-81f4-bc4522fc04c8'><active xmlns='http://jabber.org/protocol/chatstates'/><body>You received an OMEMO encrypted message, but your client does not support it.</body><encrypted xmlns='eu.siacs.conversations.axolotl'><header sid='1395287578'><key rid='1541717762'>MwohBQzkOGIo4sepqLZz/v9IdUJxAL5YCt4vzyKuKmdmsYlTEAYYAiIgxnf3nNB7cfASwVv0QqKk9j0Q1mgsOc3S78asn+U9cXnFE9SGlcjGWQ==</key><iv>+4Hi2XCCbh/agWfM/pgxKw==</iv></header><payload>YUFj+Ub0VK5CqOssN3dQ7Bu9</payload></encrypted><store xmlns='urn:xmpp:hints'/></message>

(You can safely ignore the XML parser warnings.)

Are all three clients logged in at the same time? As I said, Pidgin does not support Message Carbons, which could be a source of that problem (I'm looking into writing some hack for it). Also, would you mind moving this to its own issue, as it is not a problem with "compiling on windows", as the title says?

[dreamflasher]

@gkdr Oh yeah, sorry I didn't reply to the Message Carbons part -- yeah, that makes Pidgin pretty much unusable, is anybody using Pidgin? But yes, I assume this is the reason why I don't receive any messages at Pidgin. But that's ok, I mean I wouldn't switch to Pidgin due to this, but I nevertheless would like to see that Pidgin can send messages. So the devicelist part works.

(16:59:12) lurch: lurch_msg_encrypt_for_addrs: trying to encrypt key for 1 devices

But I have more than 1 device... It's only finding itself, not the other devices.

[aladar42]

I'm having the same(?) problem. I got the plugin to load, but when I message someone, it goes thru unencrypted, and I can't recieve their OMEMO encrypted messages. All I can see in the log is:

(17:31:19) jabber: XML parser error for JabberStream 04D9EFB0: Domain 3, code 100, level 1: xmlns: URI eu.siacs.conversations.axolotl is not absolute (17:31:19) lurch: received omemo message that does not contain a key for this device, skipping

[gkdr]

@DreamFlasher Please open a new issue with this and post the whole thing, so I can see the devicelists it finds (and then I of course need to know what is wrong with them), and then what the message looks like. I assume the error is somewhere inbetween. The function writing the snippet you posted to the debug log is concerned with all devices, and ignores your own - so it encrypts the message for one other device. (I might not have tested this case properly since Pidgin doesn't support you owning multiple devices anyway, but as I said, I'm on it.)

@aladar42 Can you also please open a new issue? And I also need some debug log output - it would be best if you opened the debug log, deactivated the plugin, and then reactivated it, so I can see what it does when it starts. If it happened right after you activated it, it might have been an issue with triggering the initialization that I identified yesterday and am currently working on.

@EionRobb Can you please tell me if you can compile it from the master branch now and if so, close this issue? Also, may I post your link to the README?

[aladar42]

I'm not sure what to paste without revelaing information about myself or the contacts, could you help me with that? I've removed my and my contact's jabber IDs, but is there anything more? I assume the keys are sensitive too?

[EionRobb]

@gkdr still a few issues

• The #ifndef NO_THREADS check needs to be added around the contents of the axc_mutexes struct
• There's still a strndup() that needs to change to a g_strndup() in axc.c

Otherwise it all compiles happily without pthreads from the master branch using -DNO_THREADS as a compile time option :)

More than happy for you to post a link to the dll. Will hopefully organise an installer to make it easier for Windows people to install

[dreamflasher]

@EionRobb I don't see a strong advantage in an installer, but what would be great to have a zip archive where alle libs are in, and the lurch.dll is in a /plugins/ subfolder, so that one can directly extract it to the Pidgin folder.

@gkdr I'll open a new ticket, yes this ticket here is way too bloated :)

[gkdr]

@EionRobb Yeah, I realised I didn't actually remove pthread when linking, that happened one commit later, that's why I missed it. I'll fix those two things and set this issue to fixed at least.

@aladar42 Removing the JIDs should be enough! Nothing of what you see is confidential - that's the whole point :D And the IDs are just that - identifiers for your devices. All the "prekeys" can be public, and the published part of your identity key is the public one. And in case you were talking about the messages: The key you see is the key for the payload (encrypted by OMEMO), but it itself is actually encrypted with an axolotl/double ratchet/Signal protocol session, so no one but your conversation partner can decrypt it, or the payload. But I'm interested at the startup, at packages related to the 'devicelist' and 'bundle' - you can use the filter field to find them!

@DreamFlasher Thanks!