From klemens at posteo.de  Sun Jan 17 11:10:54 2021
From: klemens at posteo.de (Klemens Nanni)
Date: Sun, 17 Jan 2021 11:10:54 +0100
Subject: [profanity] "/oememo log on" refers to nonexistent "/chlog on"
	command
Message-ID: <YAQNLuTmGF08Io78@eru>

(Please Cc me in replies as I am not subscribed to the list.)

Running on

	$ uname -smr
	OpenBSD 6.8 amd64

	$ profanity --version
	Profanity, version 0.10.0
	Copyright (C) 2012 - 2019 James Booth <boothj5web at gmail.com>.
	Copyright (C) 2019 - 2021 Michael Vetter <jubalh at iodoru.org>.
	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: Disabled
	OTR support: Enabled (libotr 4.1.1)
	PGP support: Enabled (libgpgme 1.14.0)
	OMEMO support: Enabled
	C plugins: Enabled
	Python plugins: Enabled (3.8.7)
	GTK icons: Disabled

I noticed the following while configuring OMEMO:

	/omemo log on
	11:06:38 - OMEMO messages will be logged as plaintext.
	11:06:38 - Chat logging is currently disabled, use '/chlog on' to enable.

	/chlog on
	11:06:40 - Unknown command: /chlog on

	/help chlog
	11:06:40 - No such command.

From jubalh at iodoru.org  Sun Jan 17 11:25:28 2021
From: jubalh at iodoru.org (Michael Vetter)
Date: Sun, 17 Jan 2021 11:25:28 +0100
Subject: [profanity] "/oememo log on" refers to nonexistent "/chlog on"
 command
In-Reply-To: <YAQNLuTmGF08Io78@eru>
References: <YAQNLuTmGF08Io78@eru>
Message-ID: <20210117112528.2af88f5c@maitreya.fritz.box>

Hi,

On Sun, 17 Jan 2021 11:10:54 +0100
Klemens Nanni <klemens at posteo.de> wrote:
> I noticed the following while configuring OMEMO:
> 
> 	/omemo log on
> 	11:06:38 - OMEMO messages will be logged as plaintext.
> 	11:06:38 - Chat logging is currently disabled, use '/chlog
> on' to enable.
> 
> 	/chlog on
> 	11:06:40 - Unknown command: /chlog on
> 
> 	/help chlog
> 	11:06:40 - No such command.

Thanks for noticing. I'll fix that later.
The command has been moved a few releases ago.

In case you haven't found it yet, the new command is:
/logging chat on

From hadaqada at gmail.com  Fri Mar 12 12:41:47 2021
From: hadaqada at gmail.com (Seswu M. Fafnan)
Date: Fri, 12 Mar 2021 12:41:47 +0100
Subject: [profanity] 0.10.0: ./configure exits with error
Message-ID: <20210312124147.9ac59dee3c8d72bc6277c0dd@gmail.com>


Hello all,

I am unable to connect to my server with version 0.6.0, the package distributed for my system (while Psi does connect), so I have been trying to manually install 0.10.0 which according to someone helpful does connect as it should.

I have installed the large number of dependencies, including libstrophe-dev, but while ./bootstrap.sh exits fine, ./configure fails.

Last messages are:
checking for libmesode... no
checking for libstrophe... no
checking whether  works... configure: error:  is broken, check config.log for details

It appears that it does not find libstrophe. However, libstrophe is there.
"libstrophe0 is already the newest version (0.9.2-2)".

System is raspbian GNU/Linux 10, buster, running on a raspberry pi 3.

config.log.. does show something interesting.
Line 70-80:
------------------------------
configure:3326: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: [...]
Thread model: posix
gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1) 
configure:3337: $? = 0
configure:3326: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
------------------------------

gcc is called with -v one time, and it goes well, -V another, and it's unrecognized.
Later on there is some complaints over a missing .h file, so perhaps the entire process went astray over this and it failed to fail when it should?

Anyway, config.log included as attachment.

Kind regards, Seswu/Fluxus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: application/octet-stream
Size: 34720 bytes
Desc: not available
URL: <http://lists.notraces.net/pipermail/profanity/attachments/20210312/8b84a91f/attachment-0001.obj>

From jubalh at iodoru.org  Fri Mar 12 13:34:16 2021
From: jubalh at iodoru.org (Michael Vetter)
Date: Fri, 12 Mar 2021 13:34:16 +0100
Subject: [profanity] 0.10.0: ./configure exits with error
In-Reply-To: <20210312124147.9ac59dee3c8d72bc6277c0dd@gmail.com>
References: <20210312124147.9ac59dee3c8d72bc6277c0dd@gmail.com>
Message-ID: <20210312133416.463e2630@maitreya>

On Fri, 12 Mar 2021 12:41:47 +0100
"Seswu M. Fafnan" <hadaqada at gmail.com> wrote:

> It appears that it does not find libstrophe. However, libstrophe is
> there. "libstrophe0 is already the newest version (0.9.2-2)".

That's not the latest version. 0.10.1 is. And Profanity needs at least
0.10 :-)

Good luck!

From debacle at debian.org  Fri Mar 12 13:49:16 2021
From: debacle at debian.org (Martin)
Date: Fri, 12 Mar 2021 13:49:16 +0100
Subject: [profanity] 0.10.0: ./configure exits with error
In-Reply-To: <20210312124147.9ac59dee3c8d72bc6277c0dd@gmail.com>
References: <20210312124147.9ac59dee3c8d72bc6277c0dd@gmail.com>
Message-ID: <YEtjTPoTVvwtdmHj@fama>

On 2021-03-12 12:41, Seswu M. Fafnan wrote:
> It appears that it does not find libstrophe. However, libstrophe is there.
> "libstrophe0 is already the newest version (0.9.2-2)".
>
> System is raspbian GNU/Linux 10, buster, running on a raspberry pi 3.

I'm not familiar with raspbian, but in Debian 10 buster,
libstrophe 0.10.0 is available via the official backports. The
Debian package version is 0.10.0-1~bpo10+1. Furthermore, you can
install profanity 0.10.0-1~bpo10+1 via backports, too. But I
have no idea how this applies to raspbian, sorry.

Cheers

From martin at mdosch.de  Fri Mar 12 16:15:32 2021
From: martin at mdosch.de (Martin Dosch)
Date: Fri, 12 Mar 2021 16:15:32 +0100
Subject: [profanity] 0.10.0: ./configure exits with error
In-Reply-To: <YEtjTPoTVvwtdmHj@fama>
References: <20210312124147.9ac59dee3c8d72bc6277c0dd@gmail.com>
 <YEtjTPoTVvwtdmHj@fama>
Message-ID: <20210312151532.lwgaprwzp6nxsfnz@mdosch.de>

On 12.03.2021 13:49, Martin wrote:
>I'm not familiar with raspbian, but in Debian 10 buster,
>libstrophe 0.10.0 is available via the official backports. The
>Debian package version is 0.10.0-1~bpo10+1. Furthermore, you can
>install profanity 0.10.0-1~bpo10+1 via backports, too. But I
>have no idea how this applies to raspbian, sorry.

I'm also not familiar with raspbian, but I guess you could just take the 
armhf repo of debian backports:

apt policy profanity
profanity:
   Installiert:           (keine)
   Installationskandidat: 0.6.0-1
   Versionstabelle:
      0.10.0-1~bpo10+1 100
         100 https://deb.debian.org/debian buster-backports/main armhf Packages
      0.6.0-1 900
         900 https://deb.debian.org/debian buster/main armhf Packages

Best regards,
Martin
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigr??e  : 833 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.notraces.net/pipermail/profanity/attachments/20210312/efd80aaa/attachment.sig>

From martin at mdosch.de  Fri Mar 12 16:17:49 2021
From: martin at mdosch.de (Martin Dosch)
Date: Fri, 12 Mar 2021 16:17:49 +0100
Subject: [profanity] 0.10.0: ./configure exits with error
In-Reply-To: <YEtjTPoTVvwtdmHj@fama>
References: <20210312124147.9ac59dee3c8d72bc6277c0dd@gmail.com>
 <YEtjTPoTVvwtdmHj@fama>
Message-ID: <20210312151749.bq2wgki4nda4xlps@mdosch.de>

I forgot to mention: If you're running a headless system on your RPi you 
might go for profanity-light. :)
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigr??e  : 833 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.notraces.net/pipermail/profanity/attachments/20210312/a8765a62/attachment.sig>

From debacle at debian.org  Fri Mar 12 16:32:06 2021
From: debacle at debian.org (Martin)
Date: Fri, 12 Mar 2021 16:32:06 +0100
Subject: [profanity] 0.10.0: ./configure exits with error
In-Reply-To: <20210312151749.bq2wgki4nda4xlps@mdosch.de>
References: <20210312124147.9ac59dee3c8d72bc6277c0dd@gmail.com>
 <YEtjTPoTVvwtdmHj@fama> <20210312151749.bq2wgki4nda4xlps@mdosch.de>
Message-ID: <YEuJditGP6rVnZKz@fama>

On 2021-03-12 16:17, Martin Dosch via profanity wrote:
> I forgot to mention: If you're running a headless system on your RPi you
> might go for profanity-light. :)

+1 for profanity-light!

From lists.trs-80 at isnotmyreal.name  Fri Mar 12 21:08:56 2021
From: lists.trs-80 at isnotmyreal.name (TRS-80)
Date: Fri, 12 Mar 2021 15:08:56 -0500
Subject: [profanity] Opening aesgcm:// links
Message-ID: <fd0345808235a613b59edf8ff213c9db@isnotmyreal.name>

Hai Guise!

First, thanks a lot for all your work and for sharing Profanity!  I am
very thankful to be able to enjoy every day using a terminal based
client that is capable of handling OMEMO!  :D

So, some clients[0] send these encrypted aesgcm://... links instead of
regular https://... links when sending pictures via OMEMO.

Today I stumbled across ImageDownloader[1] which is a small java
program to decrypt these files and output the result to STDOUT.  With
a small wrapper shell script[2] it can even automatically discern
between encrypted and regular links, decoding the former and passing
the latter directly through to the browser.

So far so good.

However the problem seems to be that aesgcm:// is not recognized as a
protocol, and thus, is not clickable in the same way a "regular"
(http(s)://) link is.

Now, in fairness, I am not even sure this is an issue with Profanity
itself.  It could have more to do with my terminal for all I know
(currently using xfce4-terminal).  Or even...?

I was digging through all the Profanity settings, but could not seem
to find anything relevant.  I did not go so far as digging through
source (yet).  After spending couple hours digging into this, I
thought, maybe better ask on list, as I might be going down entirely
wrong path.

Any suggestions which direction to look would be appreciated.

Cheers,
TRS-80


[0] At least Conversations on Android and ChatSecure on iOS, that I am
aware of.

[1] https://github.com/iNPUTmice/ImageDownloader

[2] 
https://github.com/iNPUTmice/ImageDownloader/blob/master/openbrowser.sh

From jubalh at iodoru.org  Fri Mar 12 22:23:12 2021
From: jubalh at iodoru.org (Michael Vetter)
Date: Fri, 12 Mar 2021 22:23:12 +0100
Subject: [profanity] Opening aesgcm:// links
In-Reply-To: <fd0345808235a613b59edf8ff213c9db@isnotmyreal.name>
References: <fd0345808235a613b59edf8ff213c9db@isnotmyreal.name>
Message-ID: <20210312222312.1806d8aa@maitreya>

On Fri, 12 Mar 2021 15:08:56 -0500
TRS-80 <lists.trs-80 at isnotmyreal.name> wrote:

> Hai Guise!
> 
> First, thanks a lot for all your work and for sharing Profanity!  I am
> very thankful to be able to enjoy every day using a terminal based
> client that is capable of handling OMEMO!  :D
> 
> So, some clients[0] send these encrypted aesgcm://... links instead of
> regular https://... links when sending pictures via OMEMO.

Profanity 0.10.0 can open/save them :-)
See:
https://github.com/profanity-im/profanity/issues/1262
https://github.com/profanity-im/profanity/pull/1375

There is also another commandline tool which get download these files.
Done by wstrm again: https://github.com/wstrm/omemo-utils

> Now, in fairness, I am not even sure this is an issue with Profanity
> itself.  It could have more to do with my terminal for all I know
> (currently using xfce4-terminal).  Or even...?

I think that's the terminals job. But most likely none will know about
aesgcm.

Hope this helps,
Michael

From lists.trs-80 at isnotmyreal.name  Fri Mar 12 23:27:12 2021
From: lists.trs-80 at isnotmyreal.name (TRS-80)
Date: Fri, 12 Mar 2021 17:27:12 -0500
Subject: [profanity] Opening aesgcm:// links
In-Reply-To: <20210312222312.1806d8aa@maitreya>
References: <fd0345808235a613b59edf8ff213c9db@isnotmyreal.name>
 <20210312222312.1806d8aa@maitreya>
Message-ID: <1e49ff012737951c2c269e03a03b7a58@isnotmyreal.name>

On 2021-03-12 16:23, Michael Vetter wrote:
> On Fri, 12 Mar 2021 15:08:56 -0500
> TRS-80 <lists.trs-80 at isnotmyreal.name> wrote:
> 
>> So, some clients[0] send these encrypted aesgcm://... links instead
>> of regular https://... links when sending pictures via OMEMO.
> 
> Profanity 0.10.0 can open/save them :-)
> See:
> https://github.com/profanity-im/profanity/issues/1262
> https://github.com/profanity-im/profanity/pull/1375

OK, so even though I was already reading about /url in my search
through docs, this did not fully dawn on me until your hint just now,
which I tried and of course it worked.  :D

So, for benefit of other people who might be thick like myself, here
is what you do (in a buffer where you received one of these
aesgcm://... links):

/url open <tab>

Which will autocomplete the last link received.  Pressing <tab> again
gives you the one before that, etc.  Press enter and it will fetch and
decode the file and then open it up in the system browser like normal.

If you want to save instead, I presume you would use save instead of
open.

No need to click on a link then.  Which will work fine for me as I
prefer keyboard workflow anyway.

> There is also another commandline tool which get download these
> files.  Done by wstrm again: https://github.com/wstrm/omemo-utils

Interesting, thanks!

>> Now, in fairness, I am not even sure this is an issue with
>> Profanity itself.  It could have more to do with my terminal for
>> all I know (currently using xfce4-terminal).  Or even...?
> 
> I think that's the terminals job. But most likely none will know
> about aesgcm.

I think you are right, that it is up to terminal to recognize
URI/links.  I was going to pursue that some more, but as I said I
prefer keyboard anyway, so I will leave this part of research for
other people who might need it.

Thanks Michael for the very fast reply!  I had a funny feeling I was
heading down the wrong path, so I am glad I decided to post to the
list.

Have a great weekend, mate!

Cheers,
TRS-80

From stefan at devlug.de  Sat Mar 13 10:54:49 2021
From: stefan at devlug.de (Stefan)
Date: Sat, 13 Mar 2021 10:54:49 +0100
Subject: [profanity] OMEMO and OX
Message-ID: <20210313095449.2vzk2u6yixhn33df@devlug.de>

Hello,

# OMEMO

## Start Session after Roster received

I did a small change which is on master branch.
commit b460d427bc132aa088f5787a17d045d2ece172d5

Before this change, profanity has requested all OMEMO keys for all
users in the roster. Sometimes I got "Lost connection", which may due
to to much things happened during started up.

The session start will be done when you open a window. I think this is
the same what conversations / gajim doing - I have a least the
feeling. Let my know if you face any issues due to this change.
I'm not the OMEMO Power User :-)

## Trust mode

With "OMEMO - trust mode #1506" I started on the implementation of
OMEMO trust mode. There will be a new subcommand for /omemo.

	/omemo trustmode manual|tofu|blind

This is a preference setting and will be stored with /save in [omemo].

 * manual - It should be the same like it is now.
 The user has to confirm all key manually - good luck!

 * ToFu - Is not implemented yet.
 If there is no trusted key of a user, we will trust all keys.
 If there is at least one trusted key, we won't touch anything.

 * blind - Trust all new keys

Feel free to have a look into #1506 for feedback.

## Blog post about OMEMO

Maybe it would be a nice idea to have a blog post of OMEMO usage in
profanity. Maybe there is a volunteer around to write something down?
;-)

# OX

## OX: Bugfixes for OX implementation #1487

There are some bugs in OX where I started to work on and I'm
going to continue testing. If there are some volunteers for testing
etc, please let me now.

-- 
Mit freundlichen Gr??en,
Stefan

From martin at mdosch.de  Sat Mar 13 15:54:01 2021
From: martin at mdosch.de (Martin Dosch)
Date: Sat, 13 Mar 2021 14:54:01 +0000
Subject: [profanity] OMEMO and OX
In-Reply-To: <20210313095449.2vzk2u6yixhn33df@devlug.de>
References: <20210313095449.2vzk2u6yixhn33df@devlug.de>
Message-ID: <483CF844-0154-4087-9ED7-5BF4868C81CA@mdosch.de>

Will tofu show you a hint if there are new (untrusted) keys?

From stefan at devlug.de  Sat May  8 09:35:46 2021
From: stefan at devlug.de (Stefan)
Date: Sat, 8 May 2021 09:35:46 +0200
Subject: [profanity] OMEMO bug-squashing
Message-ID: <20210508073546.jeq5gp2vm7rfbeiq@devlug.de>

Hello,

I did some OMEMO tests. OMEMO is working, but there are some issues. It
looks profanity is not always consistent.

# 1) Skipping own device
https://xmpp.org/extensions/xep-0384.html#encrypt

It looks it will be done via chat messages, but not via groupchat.
We may should add the same rule into the groupchat?

# 2) New buddy will join a MUC

You are in a room. New buddy joins the room ( not in the roster )
Do we get the device list? Maybe not at the right time?

# 3) When do we get this message?

08/05/2021 08:40:57: prof: INF: [OMEMO][SIGNAL] We've already setup a session for this V3 message, letting bundled message fall through...
08/05/2021 08:40:57: prof: INF: [OMEMO][SIGNAL] Bad MAC
08/05/2021 08:40:57: prof: WRN: [OMEMO][SIGNAL] Message mac not verified
08/05/2021 08:40:57: prof: WRN: [OMEMO][SIGNAL] No valid sessions

Maybe if we try to decrypted a message with no RID of our device.
Messages from own device?

Do we check - before decryption, if the message has been encrypted for the current device?
( Should be possible?! - are we doing this currently? )

# 4) MAM

When I open a chat window with a buddy. I get ( maybe via mam ) 

22:19:36 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
22:19:40 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
22:21:10 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.

# 5) untrust a trusted fingerprint

untrust a fingerprint of contact which is not in the roster, is working.
Depending on the trust / untrust I can read or not read the message.
=> OK

In the log file I can see an error
08/05/2021 09:21:32: stderr: ERR: (profanity:1486): GLib-CRITICAL **: 09:21:32.453: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed

# Logging

I think we should add some more logging for the OMEMO functionality.

-- 
Mit freundlichen Gr??en,
Stefan ( xmpp:stefank at conversations.im )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.notraces.net/pipermail/profanity/attachments/20210508/e3147bb3/attachment.sig>

From martin at mdosch.de  Sat May  8 10:33:46 2021
From: martin at mdosch.de (Martin Dosch)
Date: Sat, 8 May 2021 10:33:46 +0200
Subject: [profanity] OMEMO bug-squashing
In-Reply-To: <20210508073546.jeq5gp2vm7rfbeiq@devlug.de>
References: <20210508073546.jeq5gp2vm7rfbeiq@devlug.de>
Message-ID: <20210508083346.jimvfpwz6xdmrbqr@mdosch.de>

Hello together,

>I did some OMEMO tests. OMEMO is working, but there are some issues. It
>looks profanity is not always consistent.

I agree, it works but there are some issues. Especially the one where it 
can't find keys to encrypt after a reconnect (#1530) is a bit annoying.
Hopefully I find some more time to have a closer look and help debugging 
than I had in the last weeks.

># 4) MAM
>
>When I open a chat window with a buddy. I get ( maybe via mam )
>
>22:19:36 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
>22:19:40 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
>22:21:10 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.

Afaik this is a known issue as the experimental MAM support also reads 
OMEMO messages from MAM and due to the nature of OMEMO (PFS in this 
case) it's not possible to decrypt a message twice. Profanity should not 
show this for messages received from MAM and rather show the messages 
from the local DB.

Best regards,
Martin
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigr??e  : 833 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.notraces.net/pipermail/profanity/attachments/20210508/b3af0372/attachment.sig>

From stefan at devlug.de  Sat May  8 19:04:47 2021
From: stefan at devlug.de (Stefan)
Date: Sat, 8 May 2021 19:04:47 +0200
Subject: [profanity] OMEMO bug-squashing
In-Reply-To: <20210508073546.jeq5gp2vm7rfbeiq@devlug.de>
References: <20210508073546.jeq5gp2vm7rfbeiq@devlug.de>
Message-ID: <20210508170447.bet725dc5cslskt2@devlug.de>

On Sa, 2021-05-08 09:35:46, Stefan wrote:
> # 1) Skipping own device
> https://xmpp.org/extensions/xep-0384.html#encrypt
> 
> It looks it will be done via chat messages, but not via groupchat.
> We may should add the same rule into the groupchat?
> 
> # 2) New buddy will join a MUC
> 
> You are in a room. New buddy joins the room ( not in the roster )
> Do we get the device list? Maybe not at the right time?
> 
> # 3) When do we get this message?
> 
> 08/05/2021 08:40:57: prof: INF: [OMEMO][SIGNAL] We've already setup a session for this V3 message, letting bundled message fall through...
> 08/05/2021 08:40:57: prof: INF: [OMEMO][SIGNAL] Bad MAC
> 08/05/2021 08:40:57: prof: WRN: [OMEMO][SIGNAL] Message mac not verified
> 08/05/2021 08:40:57: prof: WRN: [OMEMO][SIGNAL] No valid sessions
> 
> Maybe if we try to decrypted a message with no RID of our device.
> Messages from own device?
> 
> Do we check - before decryption, if the message has been encrypted for the current device?
> ( Should be possible?! - are we doing this currently? )
> 
> # 4) MAM
> 
> When I open a chat window with a buddy. I get ( maybe via mam ) 
> 
> 22:19:36 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
> 22:19:40 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
> 22:21:10 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
> 
> # 5) untrust a trusted fingerprint
> 
> untrust a fingerprint of contact which is not in the roster, is working.
> Depending on the trust / untrust I can read or not read the message.
> => OK
> 
> In the log file I can see an error
> 08/05/2021 09:21:32: stderr: ERR: (profanity:1486): GLib-CRITICAL **: 09:21:32.453: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed
> 
> # Logging
> 
> I think we should add some more logging for the OMEMO functionality.

I just pushed some changes to my branch with the pull request:
https://github.com/profanity-im/profanity/pull/1526

* 213390e 
  When the User generates an OMEMO key, we will display the Device ID.

* 634f412
  Added some info logging, we can change it to debug, after bug-squashing

* 1c2f716
  There are two changes.
  We will display an error message to the user, when we are not able to
  find a device id for a JID.  It will be helpful for OMEMO within MUC, where
  maybe one JID has no device ID.

  I changed the "own device". We will a) never encrypted to own device.
  This should solve Issue #1 and #3 above.

  This "own device" check was also just on "device id". I added the check
  to own JID + own device id.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.notraces.net/pipermail/profanity/attachments/20210508/103860df/attachment.sig>

From stefan at devlug.de  Thu May 13 09:00:21 2021
From: stefan at devlug.de (Stefan)
Date: Thu, 13 May 2021 09:00:21 +0200
Subject: [profanity] XEP-0085: Chat State Notifications
Message-ID: <20210513070021.pecjqekyqzmworns@devlug.de>

I found in my log files something like this:

ERR: Message received without body for room: ....

I was looking into this implementation and I'm also wondering how it should
be implemented with OMEMO (0.7.0) / OX.

This message is from xmpp/message.c _handle_groupchat. Same kind of message
are defined in _handle_muc_private_message.

I was wondering if the implementation of XEP-0085 is at the right place.
The _handle_chat_states is called by _handle_chat.

I was thinking about moving it to _message_handler and stop processing
of the message handling. There may one point we need to take care,..

In stanza_contains_chat_state (xmpp/stanza.c) we may need to remove the
"content message" notifications. I think it will be only the <active/>,
which need to removed from the implementation. When I understood well, all
others are "standalone notification".

# Background

There are two kinds of chat notifications.

* content message
* standalone notification

Because OMEMO and OX are going to use XEP-0420: Stanza Content Encryption.
I was wondering, if those information should be part of the <message/> or
within the <payload/>.

It may be important for servers to know the kind of message (CSI/push
filtering). It means, we *may* not encrypted "standalone notifications".
The Server has to know, that there is not need to push for <pause/> etc.

If we would use E2EE for those information, the server do not know how it
should be processed. => Don't use E2EE for "standalone notification" may
solve this problem.

If <active/> will be part of <message/> or <payload/> doesn't matter here,
because there will be a body and we need to continue with "normal" message
processing.

-- 
Mit freundlichen Gr??en,
Stefan (DebXWoody)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.notraces.net/pipermail/profanity/attachments/20210513/fd257dbc/attachment-0001.sig>

From stefan at devlug.de  Sat May 15 20:38:05 2021
From: stefan at devlug.de (Stefan)
Date: Sat, 15 May 2021 20:38:05 +0200
Subject: [profanity] OMEMO bug-squashing
In-Reply-To: <20210508073546.jeq5gp2vm7rfbeiq@devlug.de>
References: <20210508073546.jeq5gp2vm7rfbeiq@devlug.de>
Message-ID: <20210515183805.4kwdoxvlidky5npn@devlug.de>

On Sa, 2021-05-08 09:35:46, Stefan wrote:
> # 1) Skipping own device
> https://xmpp.org/extensions/xep-0384.html#encrypt
> 
> It looks it will be done via chat messages, but not via groupchat.
> We may should add the same rule into the groupchat?
> 
> # 2) New buddy will join a MUC
> 
> You are in a room. New buddy joins the room ( not in the roster )
> Do we get the device list? Maybe not at the right time?
> 
> # 3) When do we get this message?
> 
> 08/05/2021 08:40:57: prof: INF: [OMEMO][SIGNAL] We've already setup a session for this V3 message, letting bundled message fall through...
> 08/05/2021 08:40:57: prof: INF: [OMEMO][SIGNAL] Bad MAC
> 08/05/2021 08:40:57: prof: WRN: [OMEMO][SIGNAL] Message mac not verified
> 08/05/2021 08:40:57: prof: WRN: [OMEMO][SIGNAL] No valid sessions
> 
> Maybe if we try to decrypted a message with no RID of our device.
> Messages from own device?
> 
> Do we check - before decryption, if the message has been encrypted for the current device?
> ( Should be possible?! - are we doing this currently? )
> 
> # 4) MAM
> 
> When I open a chat window with a buddy. I get ( maybe via mam ) 
> 
> 22:19:36 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
> 22:19:40 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
> 22:21:10 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
> 
> # 5) untrust a trusted fingerprint
> 
> untrust a fingerprint of contact which is not in the roster, is working.
> Depending on the trust / untrust I can read or not read the message.
> => OK
> 
> In the log file I can see an error
> 08/05/2021 09:21:32: stderr: ERR: (profanity:1486): GLib-CRITICAL **: 09:21:32.453: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed

# 6) Republish after clean-up

It looks we are not going to republish the own deviceId after clean-up from
another client. 1) Clean-up device list in gajim 2) Start profanity.
I would expect profanity will publish his device. It looks it's not the
case?!
 
> # Logging
> 
> I think we should add some more logging for the OMEMO functionality.



From stefan at devlug.de  Sun May 23 09:45:39 2021
From: stefan at devlug.de (Stefan)
Date: Sun, 23 May 2021 09:45:39 +0200
Subject: [profanity] [Feature Request] Flag a Window as important / Favorit
Message-ID: <20210523074539.5qa2ynn3jksyceqq@devlug.de>

# Feature Request

Let the user mark a window as unread / important / Favorit.

# Discussion

We shouldn't mix the concept of "unread" and "flag". Those concepts
are different. The unread flag will be unset by profanity, while
un-flag a window is a decision by the user.

# Idea

Introduce a new property of a window. Window can be a normal chat
window also a groupchat window (MUC) - let's call this property
"favorit-flag".

By default the "favorit-flag" is false. The user is able to set this
flag to true, "Flag the Window as important / Favorit". The user is
able to unset this flag for each window separate.

If a window will be closed, the flag won't stay in the current state (
unset via close) - same for disconnect, but not for reconnecting.

There may new commands / keybinding:

 * Toggle the "favorit-flag"
 * Switch to next flagged window
 * Display all flagged windows
 * Clean (unset) all flagged windows


-- 
Stefan

From rczlonka at gmail.com  Sun May 23 14:57:07 2021
From: rczlonka at gmail.com (Raf Czlonka)
Date: Sun, 23 May 2021 13:57:07 +0100
Subject: [profanity] [Feature Request] Flag a Window as important /
 favourite / favorite
In-Reply-To: <20210523074539.5qa2ynn3jksyceqq@devlug.de>
References: <20210523074539.5qa2ynn3jksyceqq@devlug.de>
Message-ID: <YKpRI3I2PYre0N3l@gmail.com>

On Sun, May 23, 2021 at 08:45:39AM BST, Stefan wrote:
> # Feature Request
> 
> Let the user mark a window as unread / important / Favorit.
> 
> # Discussion
> 
> We shouldn't mix the concept of "unread" and "flag". Those concepts
> are different. The unread flag will be unset by profanity, while
> un-flag a window is a decision by the user.
> 
> # Idea
> 
> Introduce a new property of a window. Window can be a normal chat
> window also a groupchat window (MUC) - let's call this property
> "favorit-flag".
> 
> By default the "favorit-flag" is false. The user is able to set this
> flag to true, "Flag the Window as important / Favorit". The user is
> able to unset this flag for each window separate.
> 
> If a window will be closed, the flag won't stay in the current state (
> unset via close) - same for disconnect, but not for reconnecting.
> 
> There may new commands / keybinding:
> 
>  * Toggle the "favorit-flag"
>  * Switch to next flagged window
>  * Display all flagged windows
>  * Clean (unset) all flagged windows

Hi Stefan,

I can't comment on the above proposal but I'd suggest using the
English spelling 'favourite' (UK) or 'favorite' (US) for the flag.

Regards,

Raf

From stefan at devlug.de  Sun May 30 09:12:53 2021
From: stefan at devlug.de (Stefan)
Date: Sun, 30 May 2021 09:12:53 +0200
Subject: [profanity] [Feature Request] Attention flag
In-Reply-To: <YKpRI3I2PYre0N3l@gmail.com>
References: <20210523074539.5qa2ynn3jksyceqq@devlug.de>
 <YKpRI3I2PYre0N3l@gmail.com>
Message-ID: <20210530071253.slzflr4figpqvj3b@devlug.de>

On So, 2021-05-23 13:57:07, Raf Czlonka wrote:
> On Sun, May 23, 2021 at 08:45:39AM BST, Stefan wrote:
> > # Feature Request
> > 
> > Let the user mark a window as unread / important / Favorit.
> > 
> > # Discussion
> > 
> > We shouldn't mix the concept of "unread" and "flag". Those concepts
> > are different. The unread flag will be unset by profanity, while
> > un-flag a window is a decision by the user.
> > 
> > # Idea
> > 
> > Introduce a new property of a window. Window can be a normal chat
> > window also a groupchat window (MUC) - let's call this property
> > "favorit-flag".
> > 
> > By default the "favorit-flag" is false. The user is able to set this
> > flag to true, "Flag the Window as important / Favorit". The user is
> > able to unset this flag for each window separate.
> > 
> > If a window will be closed, the flag won't stay in the current state (
> > unset via close) - same for disconnect, but not for reconnecting.
> > 
> > There may new commands / keybinding:
> > 
> >  * Toggle the "favorit-flag"
> >  * Switch to next flagged window
> >  * Display all flagged windows
> >  * Clean (unset) all flagged windows
> 
> Hi Stefan,
> 
> I can't comment on the above proposal but I'd suggest using the
> English spelling 'favourite' (UK) or 'favorite' (US) for the flag.

Thanks, good point. 

We just renamed it to "attention"-flag. The use case is not to highlight
favorite chats (maybe more stable and won't change often), it's more like
to have (temporary) attention on one or more conversations.

Yesterday, I pushed a first implementation[1].

# Usage

The user can toggle the attention-flag via ALT+F.

08:48:43 ! Attention flag has been activated
08:49:06 ! Attention flag has been deactivated
08:49:29 ! Attention flag has been activated

The "/wins attention" command can be used to display all windows with
attention flag.

08:51:09 - 14: Room room1 at server.tld 
08:51:09 - 21: Room room2 at server.tld 
08:51:09 - 24: Room room3 at server.tld

With ALT+M you can flying around the attention windows.

I didn't implemented "Clean (unset) all flagged windows", yet. But I also
not sure if it will be required.

[1] https://github.com/profanity-im/profanity/pull/1543

-- 
Mit freundlichen Gr??en,
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.notraces.net/pipermail/profanity/attachments/20210530/ec7cc3db/attachment.sig>

From stefan at devlug.de  Mon Jun 14 20:49:06 2021
From: stefan at devlug.de (Stefan)
Date: Mon, 14 Jun 2021 20:49:06 +0200
Subject: [profanity] OMEMO bug-squashing
In-Reply-To: <20210515183805.4kwdoxvlidky5npn@devlug.de>
References: <20210508073546.jeq5gp2vm7rfbeiq@devlug.de>
 <20210515183805.4kwdoxvlidky5npn@devlug.de>
Message-ID: <20210614184906.l27ecxypr5czxrqw@devlug.de>

Hello Profanity users and developers,

in small steps we are going to make improvements of the OMEMO implementation in
profanity.

Am Samstag, den 15.05.2021 um 20:38:08 +0200 schrieb stefan at devlug.de:
> On Sa, 2021-05-08 09:35:46, Stefan wrote:
> > # 1) Skipping own device
> > https://xmpp.org/extensions/xep-0384.html#encrypt
> > 
> > It looks it will be done via chat messages, but not via groupchat.
> > We may should add the same rule into the groupchat?

This has been implemented in group chats.
commit 64bcc06259cc74e5a368c09092e3d4ad422bbcd0

> > # 2) New buddy will join a MUC
> > 
> > You are in a room. New buddy joins the room ( not in the roster )
> > Do we get the device list? Maybe not at the right time?

I can confirm, this is not working well.

> > # 3) When do we get this message?
> > 
> > 08/05/2021 08:40:57: prof: INF: [OMEMO][SIGNAL] We've already setup a session for this V3 message, letting bundled message fall through...
> > 08/05/2021 08:40:57: prof: INF: [OMEMO][SIGNAL] Bad MAC
> > 08/05/2021 08:40:57: prof: WRN: [OMEMO][SIGNAL] Message mac not verified
> > 08/05/2021 08:40:57: prof: WRN: [OMEMO][SIGNAL] No valid sessions
> > 
> > Maybe if we try to decrypted a message with no RID of our device.
> > Messages from own device?
> > 
> > Do we check - before decryption, if the message has been encrypted for the current device?
> > ( Should be possible?! - are we doing this currently? )

I think this was related to self-encrypted messages.

> > # 4) MAM
> > 
> > When I open a chat window with a buddy. I get ( maybe via mam ) 
> > 
> > 22:19:36 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
> > 22:19:40 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
> > 22:21:10 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.

Ok, this is not implemented yet. We request MAM and display the message. We need
to change the implementation: MAM -> DB -> UI. This is a separated topic.

> > # 5) untrust a trusted fingerprint
> > 
> > untrust a fingerprint of contact which is not in the roster, is working.
> > Depending on the trust / untrust I can read or not read the message.
> > => OK
> > 
> > In the log file I can see an error
> > 08/05/2021 09:21:32: stderr: ERR: (profanity:1486): GLib-CRITICAL **: 09:21:32.453: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed
> 
> # 6) Republish after clean-up
> 
> It looks we are not going to republish the own deviceId after clean-up from
> another client. 1) Clean-up device list in gajim 2) Start profanity.
> I would expect profanity will publish his device. It looks it's not the
> case?!

I think the reason was a wrong value of the access model or the handle of own
devices.

In case of wrong access model, we will show an error message. We are currently
not able to publish a device on the device list, if the access model is not set
to open.

https://github.com/profanity-im/profanity/issues/1538#issuecomment-851033245
commit 41913a0aea082c953952fe31d81c72a101d2cca9

The issue about _handle_own_device_list has been fixed.
https://github.com/profanity-im/profanity/issues/1552
commit 8fe95399a1c2f530b9a64f2dd864d55712fa4f6a

> > # Logging
> > 
> > I think we should add some more logging for the OMEMO functionality.

Done! We added more DEBUG and INFO logging.

# Private messages in Multi User chats

The MUC-PM has been replaced to 1:1 chat for non anonymous.
commit 722d07adf68438559aeaec1ed1ce22b12a21a187

# Display OMEMO device ID

We Display the device ID when the users has generated the crytographic
materials.

# Restart OMEMO Session after lost connection

We will restart the OMEMO Session for open chat windows if we have lost the
connection and profanity has re-established the connection.

https://github.com/profanity-im/profanity/issues/1530
commit b235eb2351e8252999860bb6e35688ba1c8bd631

# Not in master, yet

## Handel PubSub headline events
https://github.com/profanity-im/profanity/pull/1562

-- 
Stefan

From takuwan at takuwan.xyz  Sun Jul 25 18:05:26 2021
From: takuwan at takuwan.xyz (takuwan at takuwan.xyz)
Date: Sun, 25 Jul 2021 18:05:26 +0200
Subject: [profanity] Missing chat history
Message-ID: <YP2LxmRmKelnj9wM@katana.localdomain>

Hi,

Since the profanity 0.11 update, the chat history is cleared once 
profanity is restarted. Only the history prior to the update is 
displayed. This is for OMEMO conversations (I do not know for plain text 
ones).

I checked in ~/.local/share/profanity/chatlogs and conversations are 
logged as expected. They are just not displayed anymore in the chat 
window on the next profanity startup.

Environment:
	OS - Parabola GNU/Linux
	WM - sway 1.6.1
	TE - termite 15
	profanity - From Arch package (see below)

Profanity, version 0.11.0
Copyright (C) 2012 - 2019 James Booth <boothj5web at gmail.com>.
Copyright (C) 2019 - 2021 Michael Vetter <jubalh at iodoru.org>.
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: Enabled (libgpgme 1.16.0)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.9.6)
GTK icons/clipboard: Disabled

Here is my configuration file (it did not change with the update):

[ui]
theme=gruvbox

history=true

time.chat=%d-%m %H:%M:%S

statuses.console=none

[omemo]
policy=automatic

omemo.char=?

log=redact

[connection]
defaccount=*****
account=*****

[logging]
chlog=true

grlog=true

[notifications]
typing=false
message=true
message.current=false
message.text=true
invite=true
sub=true
remind=60

Kind regards,

-- 
takuwan

From martin at mdosch.de  Mon Jul 26 21:34:45 2021
From: martin at mdosch.de (Martin Dosch)
Date: Mon, 26 Jul 2021 21:34:45 +0200
Subject: [profanity] Missing chat history
In-Reply-To: <YP2LxmRmKelnj9wM@katana.localdomain>
References: <YP2LxmRmKelnj9wM@katana.localdomain>
Message-ID: <20210726193445.mtukl3vjd6fjhvwt@mdosch.de>

Hi,

On 25.07.2021 18:05, takuwan at takuwan.xyz wrote:
>Since the profanity 0.11 update, the chat history is cleared once 
>profanity is restarted.

Do you really mean "restarted" or after a reconnect? If you mean the 
latter than it is an issue I also experience but nobody could reproduce 
so far, see https://github.com/profanity-im/profanity/issues/1556.

Best regards,
Martin
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigr??e  : 833 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.notraces.net/pipermail/profanity/attachments/20210726/cc66a05d/attachment-0001.sig>

From takuwan at takuwan.xyz  Sun Aug  1 08:20:25 2021
From: takuwan at takuwan.xyz (takuwan at takuwan.xyz)
Date: Sun, 1 Aug 2021 08:20:25 +0200
Subject: [profanity] Missing chat history
In-Reply-To: <20210726193445.mtukl3vjd6fjhvwt@mdosch.de>
Message-ID: <YQY9KSDRlxHqBumm@katana.localdomain>

Hi,

On 26.07.2021 21:34, martin at mdosch.de wrote:
>Do you really mean "restarted" or after a reconnect?

I really mean restarted, i.e. quit profanity and start it again. When I 
reconnect while profanity is running, I do not have the issue you 
describe.

Kind regards,

-- 
takuwan

From stefan at debxwoody.de  Sun Sep 12 14:19:39 2021
From: stefan at debxwoody.de (Stefan)
Date: Sun, 12 Sep 2021 14:19:39 +0200
Subject: [profanity] OMEMO and disco
Message-ID: <20210912121939.agohv3kqh35lcv5r@debxwoody.de>

Hello,

# Login and OMEMO

just after login we calling connection_request_features
src/xmpp/session.c: void session_login_success(gboolean)
src/xmpp/connection.c: void connection_request_features(void)

Here we are going for disco items discovery
iq_disco_info_request_onconnect(conn.domain)

When we received the features, we call 
src/xmpp/connection.c: void connection_features_received(const char* const)

There is a check:

if (
  g_hash_table_remove(conn.requested_features, jid) && 
  g_hash_table_size(conn.requested_features) == 0
)

if true, we call sv_ev_connection_features_received and than
omemo_publish_crypto_materials.

This function will add the _handle_own_device_list and request own
omemo bundles.

# Why do we need the disco? 

We are looking for the feature pubsub#publish-options
connection_supports(XMPP_FEATURE_PUBSUB_PUBLISH_OPTIONS

# What's the problem?

I saw some cases where we didn't call
"omemo_publish_crypto_materials". For instance, there was one person
with a IRC gateway. The IRC Gateway did not response to the disco iq
and we never got size = 0 if the hash map. There was also a second
case with wrong server config.

Unfortunately it *not* the same case in #1595 - we still need to
investigate.

# Solution?

Anyway, I'm wondering if it's a good idea to wait for "all" disco items
to setup OMEMO. My idea would be to wait for the "account domain" and
starte the OMEMO independently from other disco items (upload, muc.
irc,..)

See example in the patch file.

What do you think?

-- 
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Try-to-fix-OMEMO-Disco-issue.patch
Type: text/x-diff
Size: 1664 bytes
Desc: not available
URL: <http://lists.notraces.net/pipermail/profanity/attachments/20210912/a1477bc6/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.notraces.net/pipermail/profanity/attachments/20210912/a1477bc6/attachment.sig>

From fossy at dnmx.org  Sun Oct 10 15:02:49 2021
From: fossy at dnmx.org (fossy at dnmx.org)
Date: Sun, 10 Oct 2021 09:02:49 -0400
Subject: [profanity] issue 1556
Message-ID: <cb8a28b2af6a28609d911de3d1bdb002.squirrel@hxuzjtocnzvv5g2rtg2bhwkcbupmk7rclb6lly3fo4tvqkk5oyrv3nid.onion>

Hello there.
I have a bug I want to report.
It is the same bug that someone already reported:
https://github.com/profanity-im/profanity/issues/1556

Operating System: GNU/Arch Linux.
Kernel version: 5.14.10-arch1-1

Profanity, version 0.11.1
Copyright (C) 2012 - 2019 James Booth <boothj5web at gmail.com>.
Copyright (C) 2019 - 2021 Michael Vetter <jubalh at iodoru.org>.
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: Enabled (libgpgme 1.16.0)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.9.7)
GTK icons/clipboard: Disabled



From jubalh at iodoru.org  Wed Nov 10 17:22:13 2021
From: jubalh at iodoru.org (jubalh at iodoru.org)
Date: Wed, 10 Nov 2021 17:22:13 +0100
Subject: [profanity] libmesode functionality in Profanity
In-Reply-To: <CA+A8S0S=W2ROnN=RPnfj6ab55auoT9OMgFspD28tq71vpaLt=g@mail.gmail.com>
References: <CA+A8S0S=W2ROnN=RPnfj6ab55auoT9OMgFspD28tq71vpaLt=g@mail.gmail.com>
Message-ID: <6a9c4f11f3f543ee57277f24aa884fa8@iodoru.org>

 

Hi, 

On Mon, 15 Jun 2020 00:00:07 +0300 
Dmitry Podgorny
<pasis.uax at gmail.com> wrote: 

> Hi, 
> 
> I'd like to discuss the
remaining difference between libmesode and 
> libstrophe. As far as I
understand, the only functional feature of 
> libmesode is the ability
to provide a callback to verify failed 
> certificates manually.
However, I don't like this approach. When a 
> cert verification fails,
we can't trust it, because any information 
> can be fake there. And
it's a bad idea to ask users if they trust 
> cert checking just a few
unreliable strings. Instead, I propose the 
> following usecase: 
> 
>
First, libstrophe continues working based on connection TLS flags 
>
(disable, mandatory, trust, etc). Then, on cert verification failure, 
>
connection disconnects, but with error code that indicates TLS 
>
failure. Notice that libstrophe has the same behaviour now, but error 
>
code needs to be unified. Finally, new function will be provided to 
>
retrieve the certificate from connection, so application will be able 
>
to display it. 
> 
> For Profanity it will look like this: when
connection is disconnected 
> due to cert failure, Profanity will show a
help about danger and that 
> user can use the "trust" flag at their own
risk. The flag can be 
> stored in the account configuration as well.


Just as a follow up on this thread for people who follow the mailing

list: 

https://github.com/strophe/libstrophe/pull/186 integrated
libmesode 
functionality into libstrophe. 

libstrophe 0.11.0 contains
it. 

https://github.com/profanity-im/profanity/pull/1608 merged the
changes 
to Profanity. 

libmesode got deprecated:
https://github.com/profanity-im/libmesode 

And the next release of
profanity will require libstrophe >= 0.11.0 
Several distributions
already picked it up: 
https://repology.org/project/libstrophe/versions


Cheers, 
Michael 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.notraces.net/pipermail/profanity/attachments/20211110/b2151707/attachment.html>