Downloading aesgcm protocol file saves empty file

[emmatebibyte]

Downloading aesgcm:// protocol files creates a file of size 0 B.

Expected Behavior

A normal file should be created

Current Behavior

A file of size 0 B is created.

Steps to Reproduce (for bugs)

Download an aesgcm:// file with /url save

Context

I cannot download files

Environment

• Give us the version and build information output generated by profanity -v
• If you could not yet build profanity, mention the revision you try to build from
• OpenBSD 7.5-current
• libstrophe 0.13.1
• Prosody 0.12.4

[jubalh]

Works fine for me.

[emmatebibyte]

Works fine for me.

I’m sure it works fine for most—else there would be an issue already.

[jubalh]

That's why we will need more information since so far there is not much. You even didn't specify the profanity version.

[emmatebibyte]

That's why we will need more information since so far there is not much. You even didn't specify the profanity version.

That’s my bad, it’s version 0.14.0 on OpenBSD 7.5-current. What other information do you need?

[emmatebibyte]

This issue persists on OpenBSD 7.6-beta.

[emmatebibyte]

The profanity log at the default level does not give any information.

[balejk]

I have also encountered this problem recently (with Profanity 0.14.0 on musl Void Linux). I have not investigated it much but when trying to download the file manually using wget/curl, I noticed that the sender's server certificate is expired -- could that be the cause of the issue? Any chance the certificate is invalid in your case also, @emmatebibyte?

[jubalh]

Whats your tls setting?
/account set <account> tls force|allow|trust|legacy|disable

[emmatebibyte]

On August 19, 2024 8:03:52 AM UTC, balejk ***@***.***> wrote: I have also encountered this problem recently (with Profanity 0.14.0 on musl Void Linux). I have not investigated it much but when trying to download the file manually using wget/curl, I noticed that the sender's server certificate is expired -- could that be the cause of the issue? Any chance the certificate is invalid in your case also, @emmatebibyte?

I have manually downloaded attachments with curl(1) and that works fine, they’re just encrypted.

…

-- Emma Tebibyte (fae/faer) http://tebibyte.media/~emma

[jubalh]

Do they download with https://github.com/wstrm/omemo-utils/ ?

[balejk]

Whats your tls setting? `/account set <account> tls force|allow|trust|legacy|disable`

Default, so `force`. Which then probably makes sense that the download didn't succeed. Perhaps some informative error could be printed though instead of just saving an empty file, if this really was the reason in my case? I unfortunately no longer have the link available so I'm unable to test with omemo-utils. However with `--no-check-certificate` it downloaded just fine for me too before with wget (although of course encrypted).

[emmatebibyte]

On August 19, 2024 9:06:16 AM UTC, Michael Vetter ***@***.***> wrote: Do they download with https://github.com/wstrm/omemo-utils/ ?

The omut(1) utility says “Bad file” on invocation.

…

-- Emma Tebibyte (fae/faer) http://tebibyte.media/~emma

[russsharek]

Hello!

I am also running OpenBSD 7.5 and experiencing the same bug.

$ profanity --version
Profanity, version 0.14.0
Copyright (C) 2012 - 2019 James Booth <[email protected]>.
Copyright (C) 2019 - 2023 Michael Vetter <[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: libstrophe
Desktop notification support: Disabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Enabled (libgpgme 1.23.2)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.10.14)
GTK icons/clipboard: Disabled
GDK Pixbuf: Disabled

I've tried with tls set as both force and disabled, and neither allowed encrypted files to be downloaded with profanity.

/url save from the client will create a zero length file of the correct filename.

/url open will do nothing.

I was able to built omemo-utils, and use it to download and unencrypt the aesgcm url profanity was failing on.

The file opened and appears as expected.

I could not get this to work in any way with profanity.

Happy to provide other info as needed. I'd love to get this fixed.

[jubalh]

@omar-polo does this still work for you? Or did it in the past? I think you are also using OpenBSD according to another bugreport.

[emmatebibyte]

I recently found out this feature also does not work on my (rarely used) Artix Linux machine.

[sjaeckel]

That's super strange that nothing at all is printed, since there should be at least some output to either the window or the console.

Could you please verify that there's nothing printed? Because then there's maybe something else broken. E.g. we don't check the return value of pthread_create() ...

[russsharek]

Super strange, yet apparently true.

I just tested again to be sure. Nothing appears in the chat, the console, or the logs.

With /url save $LINK test, I get a folder called test in $HOME, containing a zero length file with the appropriate filename.

[omar-polo]

@jubalh sorry for the delay. Yes, I can reproduce using profanity 0.14.0 (from ports) on OpenBSD-current. It happens exactly what @russsharek said, I got an empty file. There's nothing logged as far as I can see. From the phone (conversations) I can see the attachments.

(the only patch for profanity we have in ports is to ensure the right version of python is used, so I doubt it's that)

In this case both I and the person sending me an image are using each our own instance of profanity, also running on OpenBSD, if it matters.

[russsharek]

The image sender in my case was on a different platform and client, and I could read that message on other clients without issue.