Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: download and decrypt aesgcm:// media urls #157

Open
petermolnar opened this issue Jan 18, 2021 · 4 comments
Open

Feature request: download and decrypt aesgcm:// media urls #157

petermolnar opened this issue Jan 18, 2021 · 4 comments

Comments

@petermolnar
Copy link

petermolnar commented Jan 18, 2021

I'm completely new to pidgin plugins, which is why this is not a pull request yet.

Using Conversations on Android, with http upload, if a media file gets sent inside and OMEMO message, lurch will correctly decrypt the message and display the media urls like aesgcm://example.com/upload/file

The problem is that the uploaded media file is also OMEMO encrypted, therefore simply following the URL doesn't work.
I also have https://github.com/EionRobb/pidgin-data-uri-image/ which pulls the actual media from normal <img> and displays it inline.

Would it be possible to add this functionality into lurch for aesgcm:// urls, as is download and decrypt the media along with the message?

@gkdr
Copy link
Owner

gkdr commented Jan 20, 2021

hi @petermolnar!
it would definitely be possible. i swear there was an issue about it somewhere, but i can't find it. so thanks for raising the issue 🙂 there are several complications:

  • i think at first this format was not really specified as an XEP and only used by the conversations client. now there is definitely at least a "proto-xep" whirling around somewhere. i couldn't find it with 2 seconds of web search, i'll look for the details at some other point. worst case, i can look at what the other clients do.
  • iirc, the way it works is to include the url to the file as xep-0066 out of band data, and the encrypted key is part of the link. so some plugin needs to look for these links with the aesgcm "protocol" and download them. since it's general out of band data and also used for things such as thumbnails in non-enrypted conversations, i think a more general, oob-data-specialized plugin might be more useful. but then there's one more plugin to juggle to make this stuff work... i think the people who are thankfully doing the packaging of my plugins might not want that 😬
  • the decryption itself should not be much of an issue, since the crypto is already there. it would happen on a local file though. since this is not a pidgin plugin, there is no UI code. i'd have to think about how to notify the UI of it and if i can use the plugin you mentioned. there is a UI for this plugin though - in the chatty client! i think i need to ask them how it would work for them, and probably do the same for pidgin. and for that, i need to figure out how to make this both a libpurple and conditionally also a pidgin plugin, so there's not even more plugins.

@petermolnar
Copy link
Author

petermolnar commented Jan 20, 2021

to the 1st point: I think the proto-xep you're looking for is https://xmpp.org/extensions/xep-0448.html

@petermolnar
Copy link
Author

petermolnar commented Jan 20, 2021

to the 3rd point: using it together with the pidgin-data-uri-image would need a message with <img> tags in it, so, if I understand it correctly, emitting a HTML message with the decrypted URI should do the trick for other plugins to pick it up.

It could be tied to a setting to do this or not, depending in client needs.

As in: decrypt incoming message => look for aesgcm:// => download resource => decrypt resource => identify mime type => emit a shadow (?) message, marked up in a way that other plugins could support, <img> for image, potentially simple local URLs for other media formats.

@selurvedu
Copy link

selurvedu commented Jan 20, 2021

FYI, I used https://github.com/moparisthebest/ImageDownloader for decrypting aesgcm:// URIs and downloading files (not only images), it works just fine. It is a C rewrite of a reference Java implementation. Maybe @gkdr could make use of its code.

Upd: looks like there'a also a Rust implementation now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants