Profanity: OMEMO support

[jubalh]

http://conversations.im/omemo/

Would be nice

[PMaynard]

I think this would be quiet nice, it would also attract potential new users.
The algorithm appears to be documented quite well https://github.com/trevp/axolotl/wiki and the extra XMPP specific appears to be quiet small http://xmpp.org/extensions/xep-0163.html

[quite]

Just read about OMEMO, good vibes!

[philipflohr]

A c library is available at
https://github.com/WhisperSystems/libaxolotl-c

[PMaynard]

:+1:

How functional is that library? Is there any relation to the Google summer of code person who was implementing OMEMO with conversations? It is the sister C library which they used in the conversation's GSoC development blog here

[philipflohr]

This Blog is only about the integration into Conversations. The library was developped by OpenWhisperSystems - the company behind TextSecure / Signals

There were no updates to the library - but there are also no reported issues.

[ReneVolution]

Would be possible to leverage the Python Plugins API to use e.g. https://python-omemo.readthedocs.org/en/latest/ ?

[boothj5]

@ReneVolution I'm still working on the python support (it works but need to tidy up object referencing and threading).

Releasing an ONEMO plugin along with the 0.5.0 release would be a really great thing to have, however I probably don't have time to do both the plugins framework and the plugin!

If anyone would be interested in attempting this ONEMO plugin, let me know, there are no doubt additional functions/hooks that will be needed in the API but I can implement those alongside any plugin work.

[ReneVolution]

Hey @boothj5,

i will try to work on that during a PythonCamp (https://barcamptools.eu/pycamp201604/sessions) and may need a bit help in advance.

From what i understand i need to at least have control over the actual message sending/receiving and manipulate the raw message data there. Is that correct so far? Can you give me some hints on that?

[boothj5]

Nice one.

Happy to help out as much as I can before the event.

As you say, we'll probably need to access the raw XMPP stanza's on send and receive, and the ability to send stanza's from a plugin, which is not currently in the API.

In principle this should not be too hard to add, the underlying XMPP library has various functions to get the stanza raw text, and send raw stanzas (although the latter is not in the libraries public API, again should be easy to add).

Another thing which might be useful that I'm planning to add, is to allow plugins to store and retrieve custom settings, similar to how they currently can use their own themes.

I'll keep this issue up to date as I make the changes, and feel free to post any ideas/questions etc.

[ReneVolution]

Awesome.

Yes, storing and retrieving plugin settings would be great as well. I am also working on another plugin which ON | OFF states would be great to be saved.

Also the state has to be saved per connection in the same way as with e.g. /otr start from a plugin side.

Thanks for helping with this.

[boothj5]

I've added prof.send_stanza() to the API, the python-test.py plugin has an example, sending a ping.

Also created a new issue which I'll update as the functions are added #772

[boothj5]

As per #772 the send and receive stanza hooks have been added.

I'm guessing the OMEMO plugin would return False from the prof_on_message_stanza_receive hook so it can process the data as needed, this will also need some kind of way to display the message once decrypted etc. I'll look into adding an API call prof_incoming_message() which will do all the window creation, unread message count, notifications, encryption type, message display etc as if it were a regular message.

I did originally think the receive hooks could return a modified stanza (or the original) for Profanity to continue processing similar to the send hooks. But then Profanity could easily be broken by a plugin returning a stanza it doesn't know how to process (which is not the case with sending). So it seemed better to let the plugin choose to take ownership of processing the stanza, as long as the required UI functions are available in the API.

[ReneVolution]

Wow man, that is really great news. I am really looking forward for the weekend now :).
Your decision is spot on when i think about it. Really great progress. Thanks a lot for the effort.

[ReneVolution]

Hey,

just wanted to check if there is any progress on the prof_incoming_message() hook? I have just started working on the plugin. :)

[boothj5]

@ReneVolution sorry I missed you in chat, was out all day.

How did things go? I have added a prof_incoming_message hook, which opens chat window etc.

[ReneVolution]

@boothj5 no worries.

Things did go well so far. Anyway i did not manage to create a prototype yet. The Barcamps seems to be more about talks than about coding :), Will try to work on it tomorrow.

You can follow the progress here: https://github.com/ReneVolution/profanity-omemo-plugin

Thanks for adding the missing hook. Talk to you soon.

[ReneVolution]

Hey @boothj5,

i am actually stuck with a part of the spec i can't figure out and hope you can help me out here.

"In order to determine whether a given contact has devices that support OMEMO, the devicelist node in PEP is consulted. Devices MUST subscribe to 'urn:xmpp:omemo:0:devicelist' via PEP, so that they are informed whenever their contacts add a new device. They MUST cache the most up-to-date version of the devicelist."

So, from what i understand is that i have to subscribe to the devicelist event, but i actually can't figure our how. Do i need to add this to the disco in some way?

Any help help here is desperately appreciated :)

[iNPUTmice]

So, from what i understand is that i have to subscribe to the devicelist event, but i actually can't figure our how. Do i need to add this to the disco in some way?

add _urn:xmpp:omemo:0:devicelist+notify_ to your disco.

Since the XEP doesn't have an official number yet both gajim and Conversations use a private namespace. So you might want to make the name space configurable in some central place and use the Conversations namespace for the time being.

Have a look here: https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/crypto/axolotl/AxolotlService.java#L54

[ReneVolution]

Thanks for helping out here. I'm happy i was on the right track :)
Unfortunately the hook for that seems to be missing. Will open another Issue for that then.

[cryptono]

@ReneVolution Any news? Are you still working on it?

[ReneVolution]

I am indeed. But still can't confirm any ETA for it.

[shibumi]

Any News about this issue? CC: @ReneVolution

[ReneVolution]

Ooohh /o\ ... this one fell so off my radar. Will try to catch up next weekend.
Sorry for the delay.

[moridius]

Keep it up! Would be awesome to have OMEMO in Profanity!

[ReneVolution]

As promised, i took some time to work on that plugin. It works now with Conversations.im (see Screenshot attached).

Anyway, there is still some stuff to do on this as e.g.

• packaging the plugin and make deployment easy
• add more testing
• refactor some of the nasty code parts
• run tests via travis
• etc.

As for the deployment, the idea would be to create and deploy a PyPI package which runs a post-install script that would register the profanity-omemo-plugin automatically. The plugin then could be enabled/disabled via the /omemo command.

Anyone any ideas/thoughts on this?

[tristan-k]

I tried to use the omemo-plugin with Profanity, version 0.6.0dev.master.b646469 but after doing /plugins install profanity-omemo-plugin/omemo.py and /plugins load omemo.py I'm getting:

15:48:43 - Could not import OmemoState
15:48:43 - Failed to load plugin: omemo.py

Are there any dependencies I'm missing?

[bascht]

@tristan-k the Plugin needs the python-omemo package. Try installing it for your user via

pip install --user git+git://github.com/omemo/python-omemo.git@158b0a236d93b10d9c3b7ecea6c53254967f7b01

[ReneVolution]

@tristan-k As stated in the README, the plugin is not yet ready to use and will not work as expected.

Currently, the connection to the server gets dropped after sending the bundle information. I can't find any relevant log entry (not even in DEBUG mode) which makes me stuck in development on this for now. Seems i have to run my own XMPP server to debug this.

[iNPUTmice]

If the connection gets dropped immediately this sounds like an error in
your xml stanza. (or maybe missing id or something but probably the former)
Feel free to post the xml here and I have a look.
As an alternative I can suggest installing gajim and using the xml console
to manually send stanzas (and get the error message)

[boothj5]

Don't know if it helps, but profanity has an XML console too, "/xmlconsole".

You can also send XML stanzas, although you'd probably need the paste.py plugin to paste multi line clipboard contents.

[ReneVolution]

Hey @iNPUTmice,

i was thinking the same, at least it is valid XML. What would be the best way to validate a stanza?

This is the stanza which might be the bad one:

<?xml version='1.0' encoding='utf8'?>
<iq xmlns:ns0="http://jabber.org/protocol/pubsub" xmlns:ns1="eu.siacs.conversations.axolotl"
    from="[email protected]" id="af583cf7-0f2c-41ef-8782-d64f58d0d648" type="set">
    <ns0:pubsub>
        <ns0:publish node="eu.siacs.conversations.axolotl.bundles:1320702624">
            <ns0:item>
                <ns1:bundle>
                    <signedPreKeyPublic signedPreKeyId="55297">BR1YnWJQbU82ze7HBvN3ZG30dptQMCAg+6YfUP/XWRdQ
                    </signedPreKeyPublic>
                    <signedPreKeySignature>
                        M+mjKFXdYPRkyyl3Djhqepjy9Q/CNffBHla4OtZ9baPVFJ69K1L7bbtxO6MrJysR8ELswdlRqVqMtbN/fBbRjA==
                    </signedPreKeySignature>
                    <identityKey>Ba5NVc2q/igvyrIz0yqA5aSZfeRogeV0syRLmal4jtgM</identityKey>
                    <prekeys>
                        <preKeyPublic preKeyId="16491473">BZBlao/O3UOWItPkABStXp3PkI0EfPevsLiwgfBtbfA4</preKeyPublic>
                        <preKeyPublic preKeyId="16491474">BQqb6ET56475eMcmCOd9ye6pNfLBXL5DGHLQ/lkNbGAe</preKeyPublic>
                        <preKeyPublic preKeyId="16491475">BYoy+tNVOdkIPiqRHlMtrCUmwuyMDummC5F4qdhuA75x</preKeyPublic>
                        <preKeyPublic preKeyId="16491476">BWkhbX79YqZ/dIAh1oVwnVtqajjStt5n9DoOM8eu6Ggn</preKeyPublic>
                        <preKeyPublic preKeyId="16491477">BXXLSfD3py/DKDXphnOSrakHRgzx3Mu+Wd8nUqS0t1gG</preKeyPublic>
                        <preKeyPublic preKeyId="16491478">BZJuvUP6z0sWNeI4NR8pxCLWUCv4QSZZeV01I2/YcXN/</preKeyPublic>
                        <preKeyPublic preKeyId="16491479">Bew8gX9zZn9NDnwdZlvpfZcx8JbB4z8OHsGOiQAniQFp</preKeyPublic>
                        <preKeyPublic preKeyId="16491480">BTzdrcdCaTtE4aMXJwbj1re0Y5lcgEL6YlD8HppcJnot</preKeyPublic>
                        <preKeyPublic preKeyId="16491481">BWLl5opvvNfzdaONCEsf+RpyhgCbLYt4oZylHYb1I1sK</preKeyPublic>
                        <preKeyPublic preKeyId="16491482">Bf8yJMbLYdQOnmAFmvlc+zJWQZWSDXEutQSCDg95/A4T</preKeyPublic>
                        <preKeyPublic preKeyId="16491483">BQdC8lB1zvKPSOA880YtJ0ZTlbxbYbWCZvBU7FaUJdAr</preKeyPublic>
                        <preKeyPublic preKeyId="16491484">BbvOpArFwt003QOEa2tB5SpA8gdyynI5ResTnZ0Ueuwq</preKeyPublic>
                        <preKeyPublic preKeyId="16491485">BVaVkfMdM09VvGxKUXTOUFwpSQ/xNv+WalZgFoq4vugd</preKeyPublic>
                        <preKeyPublic preKeyId="16491486">BZaYmS7jlOONNSh85SREwH6vkpQ7lJhqLsi64AEoDnYW</preKeyPublic>
                        <preKeyPublic preKeyId="16491487">BaByCWDYayaahNxnR/1ydKOw/xDd0Q59by5kY8mxRn5X</preKeyPublic>
                        <preKeyPublic preKeyId="16491488">Bdhh9pGvGL8JqShaQcJeSTy9za1Y4IW6ZPX3lxEBS9VJ</preKeyPublic>
                        <preKeyPublic preKeyId="16491489">BR73B5GjRXvvtgI2hzLmrhORvgVEUh0AXUOVVi/woKha</preKeyPublic>
                        <preKeyPublic preKeyId="16491490">BdFCa+/Cce+iPSi3yYU3zNVoJCoSq44rzrDArR13cW50</preKeyPublic>
                        <preKeyPublic preKeyId="16491491">BVvcMJmiBxvG2KZ+T1jkouBSLlqOBxMs1ozpoddJPIkt</preKeyPublic>
                        <preKeyPublic preKeyId="16491492">Bai2sH/eJdMIQEgH3oJXdtiQqqVDCwAxpEJ1mBMsVF4C</preKeyPublic>
                        <preKeyPublic preKeyId="16491493">BWgnzoMH+tXqbQLk50+kjgnnhNgDo4zllZjLf50hFKtq</preKeyPublic>
                        <preKeyPublic preKeyId="16491494">BWCUXxe7JY90CxdxI7vk3UbqzCATGe5jnkNxgdGV7XdJ</preKeyPublic>
                        <preKeyPublic preKeyId="16491495">BQenA4uMJtgjqwPZrIl0eFlRFg8g9yglX2QGashYVqk8</preKeyPublic>
                        <preKeyPublic preKeyId="16491496">BdZpt5/Md9I6nkMMKx25SLImU4PtWSVSfiXORP+247dU</preKeyPublic>
                        <preKeyPublic preKeyId="16491497">BWVlFEK3Joka4jHY/pRGjWHoOfEcU4YLzko79gslHTst</preKeyPublic>
                        <preKeyPublic preKeyId="16491498">BfDOfVkWMv4VE70M1U/bWnEiL6XcGl9TyDc7UGVEe58f</preKeyPublic>
                        <preKeyPublic preKeyId="16491499">BfzH2uJNzoo+UtV9VV1wQbQUhKZxJcsxLEhKv1FToCRQ</preKeyPublic>
                        <preKeyPublic preKeyId="16491500">BdS5RxxF6OR3qtuIfLH7q2bH46/vD/4PYlcKUXRZ/k4v</preKeyPublic>
                        <preKeyPublic preKeyId="16491501">BcMIztOj1BEKsJnTePkbKRPgrhvlaQyGhZ4+zHhlnmBn</preKeyPublic>
                        <preKeyPublic preKeyId="16491502">BTiP+O6QWkMCYjkUnYDdJk4pLokvIWnFdCX3AhOs0gBB</preKeyPublic>
                        <preKeyPublic preKeyId="16491503">BTdqcCfabX1JpgJhOi/FZLPIFd4BVL16vxYEA3sgkOJh</preKeyPublic>
                        <preKeyPublic preKeyId="16491504">BYrPKXVUb6Sl73ICuqXt6YqcOa2o8tC92G+IcenLgQkl</preKeyPublic>
                        <preKeyPublic preKeyId="16491505">BZDcATQgleb2BczxcqxcYtEA7691z7Ahh4dnq9zD5w5Q</preKeyPublic>
                        <preKeyPublic preKeyId="16491506">BZ5VOqiVZcZ4gpiegh49gG22VGZQKcfiYqVQZMmPNQgH</preKeyPublic>
                        <preKeyPublic preKeyId="16491507">BYIV5ZgubR7ii1fqWPZXuDKOZnqpSXSRDdbDs7CjYpo5</preKeyPublic>
                        <preKeyPublic preKeyId="16491508">BaWnZrFEzVVkzczuNSUb9dIz9+FGA4mmDv4Nc89u0dMc</preKeyPublic>
                        <preKeyPublic preKeyId="16491509">BQ3KtpwWC+75mS4pRhUEWjz7XpTkAkQO2hEAxeuyN+NH</preKeyPublic>
                        <preKeyPublic preKeyId="16491510">BVpklqqNGhklMWhNSkDnBUYqB5xOg8vJ5vl6lfEvag11</preKeyPublic>
                        <preKeyPublic preKeyId="16491511">BdxKTBfXQUE2/tCdiAesLNeJxIsBtFc1kllO+r43LnAo</preKeyPublic>
                        <preKeyPublic preKeyId="16491512">BScVyni+myu4M9363mpdcctDSR5jK1u2YfbzkmcMZgoY</preKeyPublic>
                        <preKeyPublic preKeyId="16491513">Bdr9m2AOsvY21g1g/KbAh+pUDAO8qST4P4qrCc5AuPMx</preKeyPublic>
                        <preKeyPublic preKeyId="16491514">BQYudb/G4custZmaRdSh80Ti/UwQUDdQs6cvNg0jqnlP</preKeyPublic>
                        <preKeyPublic preKeyId="16491515">BYkaSwd996PkHHgA3/dtAohNNPOpH25Msp6/oHlei20J</preKeyPublic>
                        <preKeyPublic preKeyId="16491516">BeuDgWxZno3h+QicUdXsV6pOpTuLuI4WrzcGIVEpgdo0</preKeyPublic>
                        <preKeyPublic preKeyId="16491517">Bedu89COCrQIZYBDKfa47YyrrAsLhj7ZQ+hD/S45/gUw</preKeyPublic>
                        <preKeyPublic preKeyId="16491518">Baa+HQ2/a4sRETl3M8lDkbTpCQ2Pu+Km2/MiW1bTcqMS</preKeyPublic>
                        <preKeyPublic preKeyId="16491519">BRH02p30VOmOTSRhGEOF0d4VA5sNbG9kyJbfXpXThRU+</preKeyPublic>
                        <preKeyPublic preKeyId="16491520">BdPtcMAnoJmXlUQPL7G6GK3S6k0ZiRr3NYR/ATJtXXdB</preKeyPublic>
                        <preKeyPublic preKeyId="16491521">BfYUdbIJ2c8OYpy+2XJ2qV6R5pX9xaM4ze4AxxGghK5e</preKeyPublic>
                        <preKeyPublic preKeyId="16491522">BXWotxHmMlXRCFuv5NNoitzpP/FFYqNIAbh8LDWRzAwL</preKeyPublic>
                        <preKeyPublic preKeyId="16491523">BUJPbhbe1mDSk8tcI7wUtsQeBkDdotNLBts98eWPACBf</preKeyPublic>
                        <preKeyPublic preKeyId="16491524">Be5dwKfuRz9/0uOO7wHEbG9eBqgfDgIhOHn5ui1ZPYVV</preKeyPublic>
                        <preKeyPublic preKeyId="16491525">BcARytUoo/E/wdtPoI3MXyNhsduMsowGgwcf8ft7nx9T</preKeyPublic>
                        <preKeyPublic preKeyId="16491526">BST6P/oPxtgmGMoikNo8mi2QcPqhR5F96XxTavx/srUA</preKeyPublic>
                        <preKeyPublic preKeyId="16491527">BaIR55XhUpHjECkzUsOwwguaaR5Sj6zKVLVG4oVlNL55</preKeyPublic>
                        <preKeyPublic preKeyId="16491528">BUcPUAHj3xuxhXehMJpwmGMVuek/rGVZ576TyraWadRb</preKeyPublic>
                        <preKeyPublic preKeyId="16491529">Ba1c9lUpSp4O5CR/pzAbuG0eXAI4Jh9+ECWb0fQSbR4E</preKeyPublic>
                        <preKeyPublic preKeyId="16491530">BU2cBd2x77t+hfR085qIN3YKeoq1BsamJRbQ6qhiAAJv</preKeyPublic>
                        <preKeyPublic preKeyId="16491531">BYkA/ISMlwFHhYqb3mO4tJPS4f3/Z7bwryqw3U1G5iER</preKeyPublic>
                        <preKeyPublic preKeyId="16491532">BcUD2Wuj1FweMxzDv9+xdc8Ie0Hj5HKm/EymWogOxNxw</preKeyPublic>
                        <preKeyPublic preKeyId="16491533">BVSTciRAqdsyeLUTaDlJ6VLB91i2hD20V8SB3XwZ8uNN</preKeyPublic>
                        <preKeyPublic preKeyId="16491534">BQde7BOBPo+9GH7eg9aaamQUiGP20D3LqFayTx8GIPQr</preKeyPublic>
                        <preKeyPublic preKeyId="16491535">BbM2ZafkEjhLTTXTzMFR2p1Tqdg+ZZNQyQnQY0pX1QtG</preKeyPublic>
                        <preKeyPublic preKeyId="16491536">BfyOxm9l0TrZq3qpbJHQphLhrSOhSYRM/a2ipq9QOfc/</preKeyPublic>
                        <preKeyPublic preKeyId="16491537">BQfiwQ137ipc7tacryJ0PzdiMqJDMDVx2z1WjN+qGddX</preKeyPublic>
                        <preKeyPublic preKeyId="16491538">BdGluITSruxrUEl6+FHTmNhjJHwSG74CRwy9n22LUhMI</preKeyPublic>
                        <preKeyPublic preKeyId="16491539">BRj0vfstsX4+A2iodYrQml97BUdZvR9QqPzp+5/qetQn</preKeyPublic>
                        <preKeyPublic preKeyId="16491540">BSsCArf8KOqARpoAZlbyQ+ocQrxUmo7BvGJcvwCB90Fm</preKeyPublic>
                        <preKeyPublic preKeyId="16491541">BTtwUMoTYfhrh6SjDGYENp2UW5BxtvUc8HrPTibIorUz</preKeyPublic>
                        <preKeyPublic preKeyId="16491542">BWot/sHiXXL/+km4FNAg4JVoJjo9JObRM/ICzs7y881V</preKeyPublic>
                        <preKeyPublic preKeyId="16491543">BcU5BXgvQp/7ZCkv3G9hjquOQpO5UZw3uD4HMx42budc</preKeyPublic>
                        <preKeyPublic preKeyId="16491544">BfP3X6vErmrv2bAVkZiZyA76pID6qG2QQE929Gd23KZa</preKeyPublic>
                        <preKeyPublic preKeyId="16491545">BaUIF0xB+BVE1OyYXpIgIm28FpKx2faVgGqEJlglgXxg</preKeyPublic>
                        <preKeyPublic preKeyId="16491546">BUsh6BbodjPXCk1C1f4X2F7th9ydCAUX4IiBjU+zHJ07</preKeyPublic>
                        <preKeyPublic preKeyId="16491547">BcTxjgXbL3ONYCS1nbBRefOKQ4Vgq127fPdoniIsBEo/</preKeyPublic>
                        <preKeyPublic preKeyId="16491548">BYUJcOfhJ460pXJQ3g/rL6cbCx7UCs6vux84YxhEEzJb</preKeyPublic>
                        <preKeyPublic preKeyId="16491549">BSLQWqw/djvI8mkgEqUGBnt2W+b6BLjArAcSjk0Bh0VZ</preKeyPublic>
                        <preKeyPublic preKeyId="16491550">BfxxlcEcuit+GiYoGzJhGuH+kc7pBbHfE5GvUWdzWQ9N</preKeyPublic>
                        <preKeyPublic preKeyId="16491551">BWVADawYGlirPyHb3xkkNe27BMU+R6uy3mP3iz1hYO4Q</preKeyPublic>
                        <preKeyPublic preKeyId="16491552">BS3s1I/JPOX6Dr2YDJdbKPOdw3dRJIXmpOL7UugVwMI6</preKeyPublic>
                        <preKeyPublic preKeyId="16491553">BSUwEdGNth/DWHpDCrD+dx8Gmd6At8gpiUif68x/fxhV</preKeyPublic>
                        <preKeyPublic preKeyId="16491554">BQ6YfvVBotAj21U7isnuMBaUC++jGj9mlA84wxT1+pUI</preKeyPublic>
                        <preKeyPublic preKeyId="16491555">BaGveFAbOr2EzWMZVIovafyheBoEE8YpeL97PpG/sHZI</preKeyPublic>
                        <preKeyPublic preKeyId="16491556">BdMbaeRvBOEMFbZKlptlW/tJsGTWCEEriOW0Io3+yQoi</preKeyPublic>
                        <preKeyPublic preKeyId="16491557">BfE0lSisTrJkQCAKHMxzQyqz2j0rKoIazEFRskg1jCp8</preKeyPublic>
                        <preKeyPublic preKeyId="16491558">BTKKKoBN5CW2rSUZxxGPxoEyF7VBp8PAVi3UWMmeW2c+</preKeyPublic>
                        <preKeyPublic preKeyId="16491559">BS7pH8BYvOfpK8sA29o7FUkcg4awlJ2fIDZgymf/iYBU</preKeyPublic>
                        <preKeyPublic preKeyId="16491560">BaX4r5OG7Rssi0NM7xEL8p0zYCRQU8hOmqNgElN7qBwo</preKeyPublic>
                        <preKeyPublic preKeyId="16491561">BVUfqHpuik74arF3ze39a0KrscvWw+G3py2OEAChtWhv</preKeyPublic>
                        <preKeyPublic preKeyId="16491562">Bc1W+HigVNGaiZr4T48hQYQOjInSsT3E6UQ6e8xG6Icc</preKeyPublic>
                        <preKeyPublic preKeyId="16491563">Be3PowEs+H5hmsrUtieTo0DRTdDKzcPcUeT7R0VO+Eww</preKeyPublic>
                        <preKeyPublic preKeyId="16491564">Beh0zPwDYaKPLtkXBq9x6H+sdgssvxH+sj1Dcn55kv4H</preKeyPublic>
                        <preKeyPublic preKeyId="16491565">BWM6m22JrBWd/TvaI3JJMMaDsekNjS8b96/4XNWt8KZX</preKeyPublic>
                        <preKeyPublic preKeyId="16491566">BRn9Z73AYlQN2Vfw7Da6wdQKgMVVwwlrCHORVN912/JB</preKeyPublic>
                        <preKeyPublic preKeyId="16491567">BZp63RQpQ/KsOMTAQv9H1wzRZ1pTwtEj0aYi7RzegQp/</preKeyPublic>
                        <preKeyPublic preKeyId="16491568">BboujSfDVtXOxiAnukWVOCRTAP/R2549Mjl71ynV/E4D</preKeyPublic>
                        <preKeyPublic preKeyId="16491569">BTeJ4TyrnPT66oXGrAKaXralKOWUrzWA9V+z2IO4r0d9</preKeyPublic>
                        <preKeyPublic preKeyId="16491570">Baie+tK6m5USQAJPLBatWvJf7bhlzSHBWE4tY0B/ypoj</preKeyPublic>
                        <preKeyPublic preKeyId="16491571">BaYiBRM00mrAmATguprd6pA07Z/VuxnBV9N6LV/s/AZ5</preKeyPublic>
                        <preKeyPublic preKeyId="16491572">BYu+A2yFsKgxKLjCoQiqukdvb6ZmNq7dDTMJddrYAjEJ</preKeyPublic>
                    </prekeys>
                </ns1:bundle>
            </ns0:item>
        </ns0:publish>
    </ns0:pubsub>
</iq>

[iNPUTmice]

@ReneVolution first of all you don't send the <xml version='1.0' encoding='utf-8'?>
Second of all the way your XML library adds the namespace prefixes isn't valid XMPP. See the OMEMO XEP for how the namespaces should look like. Your xml library puts the namespaces all in the parent element instead of the individual elements. (There is a word for that mode but it doesn't come to my mind right now. In any case XMPP uses the 'other' mode.)

You might actually be better of writing that XML by hand instead of with a library. (I assume the <?xml... is also generated by your library.

[ReneVolution]

@iNPUTmice i was actually wondering exactly that when copy+pasting it for you.
Will work on that and keep you posted. Thanks for looking into this.

[ReneVolution]

@iNPUTmice That did the trick. Thanks a ton. I could swear i did not change that since it worked the last time ... anyway, always better to stick with the specs :)

[vestingz]

Thanks a ton for making this possible! Unfortunately, it doesn't even install:
16:50:11 - Failed to install plugin: omemo.py
I'm using profanity v0.6.0dev.master.b646469 with the python-omemo package installed, like @bascht suggested.

[ReneVolution]

@vestingz Sorry for the inconvenience on that. Unfortunately the plugin is not yet ready for general availability and i am actually refactoring it to make the install process as painless as possible.

I will keep you all updated here once it is ready for beta testing.

Thanks for your patience.

[NiklausHofer]

https://www.bountysource.com/issues/27781988-omemo-support

[ReneVolution]

Hey there,

i have created some issues at https://github.com/ReneVolution/profanity-omemo-plugin/issues for better visibility what is currently missing for the plugin and in what stage it is.

As you can see, the plugin is already at a good stage with some limitations which should be fixed very soon. Please watch the repo for updates.

Cheers,
René

[herbsmn]

Can it be said that @ReneVolution's plugin has fulfilled this ticket? Or is it still not a done deal becaue it isn't out of Alpha or Beta testing?

If you commented on this issue and haven't tested https://github.com/ReneVolution/profanity-omemo-plugin/issues yet, can you please do so and submit issues and patches?

Thanks for your work on this René!

[ghost]

I've just tested with the latest commits on everything and the "Failed to load plugin" problem remains.

[strugee]

@boothj5 I wonder if you'd consider bundling @ReneVolution's plugin with Profanity core installs? Seems like OMEMO is gaining steam and that would provide a better out-of-the-box experience while not significantly increasing code/maintenance complexity.

[ReneVolution]

@bashrc: Can you provide any logs that could point to what is going wrong?

[ReneVolution]

@strugee I think there are too many Python related dependencies to bundle it directly with profanity. What I think would probably work is some kind of post-insall that could be run from profanity itself. A little bit "AppStore" like as for example in Atom.io. That could then work for other extensions as well.

@boothj5: Any thoughts on that?

[strugee]

@ReneVolution packages of Profanity could just mark those dependencies as optional, right? Although I guess that half defeats the point :D

[varac]

+1 for shipping omemo integrated into profanity!

Any news on this, looks like no progress since a few month... ?

[reedts]

Just to revive this thread a little bit: I'm working on an alternative OMEMO plugin in C but had no time to spare the last 10 months or so. I think there is still demand? It is really very very very early WIP but I will continue working on it as I have time.

[jubalh]

@reedts personally I would love to have a plugin in C which can easily be shipped with profanity, maybe even integrated.

Maybe mentioning your repo in case others want to contribute would be good to.
I suppose it's https://github.com/reedts/profanity-omemo

[reedts]

@jubalh Yes that's correct.

[devhell]

@reedts Oh, that's wonderful! I'd very much love a plugin written in C. That being said, @ReneVolution has done a ton of good work too. I hope that we'll see first class support for OMEMO in profanity at some point.

[Echolon]

Hi, are there any updates about OMEMO support?
Maybe restating whats not working would help to find new impressions or people to look at.

Cheers

[reedts]

Hello there,
sorry, we had a very long unplanned halt in development primarily caused by many different personal matters, moving into a new appartement and huge load at work, followed by holiday etc....

However, there are no specific issues that keep us from moving forward apart from spare-time.

I have done a few changes over the past few weeks, I'm still working to finalise and test them. I'm hopeful to have much more spare-time at hand to continue working on this now.

Cheers

[Echolon]

@reedts Cool - looking forward to 100% ;)

https://omemo.top/

[divansantana]

Very much a demand for this. Is this working? Would like to try it out. Whats the status @reedts :smile:

[ReneVolution]

Hey everyone,

sorry for being not very responsive on this project. I've recently become a dad and so the focus shifted drastically 😸. Also, I think @reedts approach (providing a native c plugin) which may be included upstream is the better approach.

I am looking forward to see that in action. That being said, I am no longer maintaining the Python plugin. In case anyone still wants to pick it up _as-is_ - please feel free too.

Thanks. It was a great journey in a great community.
Cheers.

[reedts]

@divansantana Unfortunately still WIP.

[jubalh]

We try to have OMEMO support in profanity 0.7.0

[moridius]

That would be great! OMEMO is the only reason why I'm not using profanity anymore.

[philipflohr]

@jubalh is there any effort to implement omemo within profanity? Currently there is not much progress on the c plug in.

[jubalh]

@philipflohr yes someone started two days ago to work on implementing it directly in profanity. makes good progress. do you want to join? I saw that you cloned the c plugin recently.

[philipflohr]

I'm not sure if I'm able to do much work as I'm currently writing my master thesis but I'm interested in helping.

[paulfariello]

@jubalh @philipflohr draft PR is #1039. To do list has still some items but we can start to send receive encrypted messages.

[jubalh]

Great work @paulfariello !

[paulfariello]

1039 PR should have enough progress so it can be tested. Feel free to play with it and to comment the PR if you find any issue.

[jubalh]

When possible I always look at each commit done to the PR. It would be nice to have @pasis opinion and review at one point too. Maybe even @iNPUTmice could also take a look at OMEMO implementation.

[NiklausHofer]

Hey Guys,

I have been building new versions of profanity from the 'feature/omemo' branch for a couple of days now. However, lately profanity would get stuck during connecting to the server. I have now taken the time to find the exact commit that breaks for me.

• last working: 7f27df951d1bfdf7bfeb11f9af04da87a6234310
• first broken: 34ad7a5060a375d5da001e797939092417e65c66

What happens is that profanity starts normally, but when I type /connect it freezes after printing these lines to the UI:

16:16 - Using default account vimja.
16:16 - Connecting with account vimja as [email protected]/octarine

At this point it does no longer accept any input or print any output. Also my account never appears 'online' so I guess profanity is not sending out any further messages either. Debug output stops as well. I kann still kill the process with signal 15.

If I remove the omemo information (rm -rf .local/share/profanity/omemo/) and start profanity again, everything works as expected. However, if I re-generate new omemo keys (/omemo gen) and then restart profanity, the same error occurs again.

Here is some information for the broken version:

profanity --version

Profanity, version 0.6.0dev.HEAD.34ad7a50
Copyright (C) 2012 - 2018 James Booth <[email protected]>.
License GPLv3+: GNU GPL version 3 or later <https://www.gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Build information:
XMPP library: libmesode
Desktop notification support: Enabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Disabled
C plugins: Disabled
Python plugins: Disabled
GTK icons: Disabled



md5-c7ea2ec4041dd6b5742f2be75c2d23eb



    linux-vdso.so.1 (0x00007fffd91f5000)
    libcurl.so.4 => //usr/lib64/libcurl.so.4 (0x00007ff43879b000)
    libnotify.so.4 => //usr/lib64/libnotify.so.4 (0x00007ff438592000)
    libgio-2.0.so.0 => //usr/lib64/libgio-2.0.so.0 (0x00007ff4381ee000)
    libgobject-2.0.so.0 => //usr/lib64/libgobject-2.0.so.0 (0x00007ff437f9a000)
    libglib-2.0.so.0 => //usr/lib64/libglib-2.0.so.0 (0x00007ff437c7d000)
    libotr.so.5 => //usr/lib64/libotr.so.5 (0x00007ff437a63000)
    libgcrypt.so.20 => //usr/lib64/libgcrypt.so.20 (0x00007ff43773a000)
    libreadline.so.7 => /lib64/libreadline.so.7 (0x00007ff4374e7000)
    libncursesw.so.6 => /lib64/libncursesw.so.6 (0x00007ff43726b000)
    libmesode.so.0 => //usr/lib64/libmesode.so.0 (0x00007ff437051000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff436e31000)
    libc.so.6 => /lib64/libc.so.6 (0x00007ff436aa5000)
    libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007ff436832000)
    libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007ff436393000)
    libz.so.1 => /lib64/libz.so.1 (0x00007ff43617b000)
    libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007ff435f53000)
    libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007ff435d4f000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00007ff435b38000)
    libmount.so.1 => /lib64/libmount.so.1 (0x00007ff4358d6000)
    libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007ff4356cd000)
    libpcre.so.1 => /lib64/libpcre.so.1 (0x00007ff435488000)
    libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007ff435264000)
    libncurses.so.6 => /lib64/libncurses.so.6 (0x00007ff434ffd000)
    libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007ff434dc7000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ff438d69000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007ff434bc3000)
    libm.so.6 => /lib64/libm.so.6 (0x00007ff4348e3000)
    libblkid.so.1 => /lib64/libblkid.so.1 (0x00007ff43468c000)
    librt.so.1 => /lib64/librt.so.1 (0x00007ff434484000)
    libuuid.so.1 => /lib64/libuuid.so.1 (0x00007ff43427c000)



md5-054a5ebb0d9d4722d2f1cf7b036b4625



07/03/2019 16:16:49: xmpp: DBG: Bind successful.
07/03/2019 16:16:49: conn: DBG: SENT: <iq id="_xmpp_session1" type="set"><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></iq>
07/03/2019 16:16:49: xmpp: DBG: RECV: <iq id="_xmpp_session1" to="[email protected]/octarine" type="result"/>
07/03/2019 16:16:49: xmpp: DBG: Session establishment successful.
07/03/2019 16:16:49: prof: DBG: Connection handler: XMPP_CONN_CONNECT
07/03/2019 16:16:49: prof: DBG: Connection handler: logged in with account name: vimja
07/03/2019 16:16:49: prof: INF: Loading OTR key for [email protected]
07/03/2019 16:16:49: prof: INF: No OTR private key file found /home/sst-nho/.local/share/profanity/otr/vimja_at_xmpp.honet.ch/keys.txt
07/03/2019 16:16:49: prof: INF: No OTR fingerprints file found /home/sst-nho/.local/share/profanity/otr/vimja_at_xmpp.honet.ch/fingerprints.txt

[paulfariello]

Hi @NiklausHofer

Thanks for giving a try on this PR.
Thanks also for the detailed bug report.

Right now I have no idea why 34ad7a5 would break connection. But let's dig into it anyway.

Could you gdb attach to the stuck profanity and copy/paste me a backtrace?

[NiklausHofer]

@paulfariello Thank you for the quick reply. Here we go:

#0  0x00007f2502d4b24b in select () from /lib64/libc.so.6
#1  0x00007f25039c751c in ?? () from //usr/lib64/libgcrypt.so.20
#2  0x00007f25039c0f20 in ?? () from //usr/lib64/libgcrypt.so.20
#3  0x00007f25039c211a in ?? () from //usr/lib64/libgcrypt.so.20
#4  0x0000564da4409f2e in omemo_random_func ()
#5  0x0000564da440d165 in curve_generate_private_key ()
#6  0x0000564da440d25d in curve_generate_key_pair ()
#7  0x0000564da4416b60 in signal_protocol_key_helper_generate_pre_keys ()
#8  0x0000564da4409037 in omemo_on_connect ()
#9  0x0000564da43c4fb9 in sv_ev_login_account_success ()
#10 0x0000564da43b526f in session_login_success ()
#11 0x00007f250320c1c6 in ?? () from //usr/lib64/libmesode.so.0
#12 0x00007f250321121f in ?? () from //usr/lib64/libmesode.so.0
#13 0x00007f250320de8a in ?? () from //usr/lib64/libmesode.so.0
#14 0x00007f250321a6cf in ?? () from //usr/lib64/libmesode.so.0
#15 0x00007f2500f8820f in ?? () from /usr/lib64/libexpat.so.1
#16 0x00007f2500f8931c in ?? () from /usr/lib64/libexpat.so.1
#17 0x00007f2500f8c12b in XML_ParseBuffer () from /usr/lib64/libexpat.so.1
#18 0x00007f2503210cac in xmpp_run_once () from //usr/lib64/libmesode.so.0
#19 0x0000564da43b06d2 in prof_run ()
#20 0x0000564da43ad0df in main ()

[paulfariello]

Does it stay stuck really long?
Seems to be waiting for random data to be available.
Can you strace profanity?

[NiklausHofer]

@paulfariello You are right, it was waiting for random data. I've had it wait for several minutes before killing it. Starting rngd solved the problem, it now starts as expeted. Thank you so much for your help!

[paulfariello]

Good to know.
I'm still curious how is it possible to run out of entropy on a modern system.
Could you tell me with a strace where gcrypt is trying to gets its random?

And good to know that libsodium didn't produce such an issue :yum: .

[NiklausHofer]

@paulfariello sure. I built a new version from HEAD and disabled rngd.

strace -p 5104

strace: Process 5104 attached
select(1024, [0], NULL, NULL, {tv_sec=0, tv_usec=471145}) = 0 (Timeout)
poll([{fd=0, events=POLLIN}], 1, 0)     = 0 (Timeout)
poll([{fd=0, events=POLLIN}], 1, 0)     = 0 (Timeout)
read(4, 0x5638b82778d0, 4000)           = -1 EAGAIN (Resource temporarily unavailable)
select(1024, [0], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
poll([{fd=0, events=POLLIN}], 1, 0)     = 0 (Timeout)
poll([{fd=0, events=POLLIN}], 1, 0)     = 0 (Timeout)
read(4, 0x5638b82778d0, 4000)           = -1 EAGAIN (Resource temporarily unavailable)
select(1024, [0], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
poll([{fd=0, events=POLLIN}], 1, 0)     = 0 (Timeout)
poll([{fd=0, events=POLLIN}], 1, 0)     = 0 (Timeout)
read(4, 0x5638b82778d0, 4000)           = -1 EAGAIN (Resource temporarily unavailable)
select(1024, [0], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
poll([{fd=0, events=POLLIN}], 1, 0)     = 0 (Timeout)
poll([{fd=0, events=POLLIN}], 1, 0)     = 0 (Timeout)
read(4, 0x5638b82778d0, 4000)           = -1 EAGAIN (Resource temporarily unavailable)
select(1024, [0], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)

The output does not stop there, it keeps repeating over and over.

[NiklausHofer]

With Profanity now starting I had a chance to actually test the omemo functionality. Unfortunately, when I run /omemo start JID, profanity segfaults. Again I have searched the commit this first happens:

• last working: 8f9c68b9b2c2bc08fd8b04207f657e6fc30bdbb5
• first broken: b12bf63d686d651a4559ae97954b685f9ce3ce23

Here is what gdb prints when I start profanity through gdb:

Program received signal SIGSEGV, Segmentation fault.
                                                    0x00005555555e3f1b in omemo_sessions_keyfile_save ()

I built from the current HEAD (a38d10b8328a0154e0e3e211c67634173e3caebf) for testing, here is the version information:

Profanity, version 0.6.0dev.HEAD.a38d10b8
Copyright (C) 2012 - 2018 James Booth <[email protected]>.
License GPLv3+: GNU GPL version 3 or later <https://www.gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Build information:
XMPP library: libmesode
Desktop notification support: Enabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Disabled
C plugins: Disabled
Python plugins: Disabled
GTK icons: Disabled

[paulfariello]

@niklaushofer can you provide a full backtrace from gdb and use a debug build of profanity?

[NiklausHofer]

Here is the backtrace. It will take me a moment before I can do a debug build of the software:

#0  0x00005555555e3f1b in omemo_sessions_keyfile_save ()
#1  0x00005555555e52b1 in store_session ()
#2  0x00005555555e6fbc in signal_protocol_session_store_session ()
#3  0x00005555555efe14 in session_builder_process_pre_key_bundle ()
#4  0x00005555555e40ff in omemo_start_device_session ()
#5  0x00005555555e5c46 in omemo_start_device_session_handle_bundle ()
#6  0x0000555555593a91 in ?? ()
#7  0x00007ffff6418375 in ?? () from //usr/lib64/libmesode.so.0
#8  0x00007ffff6414e8a in ?? () from //usr/lib64/libmesode.so.0
#9  0x00007ffff64216cf in ?? () from //usr/lib64/libmesode.so.0
#10 0x00007ffff418f575 in ?? () from /usr/lib64/libexpat.so.1
#11 0x00007ffff419031c in ?? () from /usr/lib64/libexpat.so.1
#12 0x00007ffff419312b in XML_ParseBuffer () from /usr/lib64/libexpat.so.1
#13 0x00007ffff6417cac in xmpp_run_once () from //usr/lib64/libmesode.so.0
#14 0x000055555558a972 in prof_run ()
#15 0x000055555558737f in main ()

[NiklausHofer]

OK, when I compile a debug version (-O0 -g3) it does not segfault. It segfaults with -O1 though.

[jubalh]

Would be super cool if comments about the current state of the OMEMO feature branch and testing it could be done at https://github.com/boothj5/profanity/pull/1039

I think it belongs there. Thanks guys!

[jubalh]

@paulfariello did a great job with implementing OMEMO.
Several people helped with testing the feature branch https://github.com/boothj5/profanity/pull/1039, I think @kaffeekanne was especially active. Thanks to everybody involved!

I hope a code review can happen soon and then I will merge into master.

Please everybody who has some time to spare help with reviewing the code in the feature branch or help by testing the changes.
If you need help to build profanity from that branch you can find us in [email protected] where we will try to help you.

If you test the branch and everything works fine, please still comment on this issue so we know more people tested and had no issues.

Thanks guys!

[jubalh]

After 4 years this issue can finally be closed.

Thanks a lot to @paulfariello for all his work implementing this, and to @kaffeekanne for testing!
Paul, don't forget the bounty ;)