Send images as images readable from other clients (not links)

[ksdrummer]

Describe the bug Hello, I'm not a Beagle user myself, but I installed it to a friend of mine. When he send me pictures from Beagle, I receive links instead of images (from Dino and/or Conversations).

To Reproduce Steps to reproduce the behavior:

1. Open a conversation with somebody who uses another xmpp client
2. Send a picture
3. She/He will only see a link

Expected behavior When you send an image from beagle, other people should receive an image instead of a link.

Screenshots

Desktop (please complete the following information):

• OS: Archlinux
• Client : Dino 0.2.0

Smartphone (please complete the following information):

• OS: Android
• Client : Conversations 2.9.11+fcr

Thank you in advance !

[hantu85]

Please provide information which version of BeagleIM were used to achieve this results. Stable one from the AppStore or one of beta builds from GitHub/Homebrew?

[ksdrummer]

It is the stable on from AppStore. Version number : 4.1 (110) I forgot to mention this is a OMEMO encrypted conversation. So the links should be aesgcm links instead of publicly visible links. I don't know if beagle can handle aesgcm links so this may be be the problem.

[hantu85]

Thank you for reporting this issue. I've checked in the upcoming version 5.0 (beta) and it is already fixed there.

[ksdrummer]

This is perfect ! Thank you very much :+1:

[tomeksowi]

@hantu85, I can confirm it not fixed in both Beta 5.0 (128) and stable 4.1 (110).

Dragging a gif from Finder onto the input box still pastes the path, not the image.

Pasting image from clipboard (e.g. screenshot taken with Shift+Ctrl+Cmd+4) also doesn't work (error sound, nothing happens)

macOS Catalina 10.15.7 (19H1217) (I can't upgrade to Big Sur, unfortunately)

[hantu85]

@tomeksowi Pasting files or images is not supported.

This issue was about sending files as HTTPS instead of AESGSM and has nothing to do with the issue which you mentioned.

As for dragging gif from finder - it works just fine, I've just double-checked that. However, to make it work "share" button ("+") needs to be enabled in a particular conversation - without it, any file sharing with the use of HTTP File Upload will not work.

[coderobe]

Issue still exists in version 5.3 (152)

[hantu85]

@coderobe Please clarify what is actually not working for you, with what file type and BeagleIM settings related to file upload/sharing.

I've uploaded/shared OMEMO encrypted file with D&D and file selection and proper aesgcm:// was sent.

[mrusme]

Experiencing the same issue with 5.3. Pictures sent using the "+" button are plain HTTPS links instead of aesgcm links and they are visible for anyone with the link. The same account was configured on Siskin, where on the other hand Siskin correctly sends aesgcm URLs/uploads the pictures encrypted.

I made sure that in Beagle the contact to which the pictures were sent is "Verified". OMEMO session is on.

Is there any hidden setting one needs to enable for Beagle to encrypt uploads?

[hantu85]

@mrusme I've checked with 5.3 and in my tests attachments sent with the "+" button are always sent as aesgcm:// links if the conversation is marked as encrypted.

Could you check that icon on the right from the text entry field presents a lock which is closed?

Is there anything unusual about this conversation causing the issue? Is it 1-1 chat? or a group chat? Was your client connected? (where you joined?) when you sent this message?

[mrusme]

@hantu85 thank you for getting back and thank you for your effort of building this in first place!

I checked the lock, it is shown as closed. The client on the other side (profanity) also shows the conversation as OMEMO encrypted.

Unusual, hm. It's a 1-1 chat, correct. The client was connected and appeared to the other side as online. The conversation was ongoing, meaning text, upload, text, upload, etc.

The server is an ejabberd (22.05) with pretty much all modules enabled and all relevant ports reachable. Siskin does send correct aesgcm:// URLs, as does Conversations (Android), profanity (TUI) and Gajim (desktop). Both accounts are on the same ejabberd server and they are, well, regular user accounts, nothing really special about them.

The reason this was noticed is because profanity prints the file URL (as it is a TUI client). Conversations makes it look as if the message itself is indeed encrypted with OMEMO, but it contains a simple https:// URL. Every client but Beagle sends a aesgcm:// URL and hence in most clients the URL does not even become visible, as they only display the inline photo. Only Beagle uploads seem to be plain https://, making them appear as messages containing a HTTPS link.

Let me know if you need further info or if there are any logs or other things that you'd like me to check.

[hantu85]

I've found a possible issue which this could happen, if HTTP server handling upload will not respond with HTTP response code 201 as it should. This should be fixed in version 5.3.1-b162

[mrusme]

@hantu85 just tested the latest beta from the releases here and unfortunately the issue is still there. :-( Pictures are sent as regular https:// links/uploads, non-encrypted.

[hantu85]

I'm unable to replicate this issue. In all tested cases, attachment was encrypted properly and valid aesgcm:// link was generated.

[mrusme]

Can I provide further debug logging or any other information that might give new insights into this? Is there a verbose mode that can be turned on?

[hantu85]

Could you check if your encryption setting in the application Preferences? Is it set to None or to OMEMO? If to OMEMO, could you check the lock icon on the conversation view after changing default encryption value to None and the switching from and the back to this problematic conversation?

[mrusme]

@hantu85 thank you very much, it is working now! Indeed, it seems like Beagle got confused and completely disabling OMEMO and then re-enabling it has done the trick! Images are now sent as aesgcm:// links - awesome!

[uanox]

I still have the problem with BeagleIM sending images and files unencrypted as https-upload URLs, even after following the suggestion to disable and enable OMEMO - I did this a couple of times, with or without restarting BeagleIM. To no avail. Beagle just sends a https URL inside an OMEMO encrypted text message (or the same unencrypted when I disable OMEMO), instead of actually encrypting file transfer data. The problem here is that the URLs are public and Beagle stores file data unencrypted on a public html server. Version 5.3.4 (176), macOS 13.4, using xmpp server of mailbox.org provider

[hantu85]

I still have the problem with BeagleIM sending images and files unencrypted as https-upload URLs, even after following the suggestion to disable and enable OMEMO

What is the status of OMEMO encryption in the chat to which you send attachment? (lock icon on the bottom right, is it open or closed?)

How do you send attachment? using + button? drag & drop?

[uanox]

I try to send it both way - drag&drop and "+" - always sent as HTTPS URL. Lock icon is closed when preferences are set to OMEMO, open when disabled on the sender´s side. Sender and receiver are on the same XMPP server.

[hantu85]

Could you try to manually change lock to open and then to closed inside this chat? (without changing global settings)

[uanox]

When sent in OMEMO ON, the receiver will see the raw URL (in Conversations Android), when sent with OMEMO off, the recipient will see the actual image or file, not the raw URL. However, behind these files there are the unencrypted HTTPS URLs. When files are being sent to my BeagleIM Instance with OMEMO ON, I will receive an encrypted file (aesgcm://) in BeagleIM. Same XMPP server.

[hantu85]

But have you tried changing those settings for this chat (by clicking on the lock button/image and selecting other values) or are you telling me what happens when lock icon is open/closed when you changed global settings in the app preferences?

[uanox]

Could you try to manually change lock to open and then to closed inside this chat? (without changing global settings)

Ok, I tried that and it seems to do the trick. When I disable and then re-enable OMEMO via the lock icon within the chat, instead of the global settings, BeagleIM sends aesgcm:// URLs.

This seems, however, not very intuitive. Global prefs should behave consistently. Thanks for pointing out the workaround.

[hantu85]

I agree that this should be consistent, however I wanted to narrow down the source of the issue. Thank you for helping out.