Repository navigation
Add support for XEP-0363: HTTP File Upload #681
Description
Activity
We're not TextSecure ;)
But yeah! I was actually working on this today.
Reacted by Gerben Peeters, Mathijs van Gorcum, Felix, afriedmanGlacier and LReacted by SemperverusOh wow, that sounds pretty awesome! 👍
And a derp from me hehe, already sleepy, so i said the wrong name, oops :')
Oh dear god yes, please!
The only request I can add on top of this is to have it automatically decrypt incoming OMEMO-encrypted images and inline them for viewing.
Reacted by afriedmanGlacier and LThe only request I can add on top of this is to have it automatically decrypt incoming OMEMO-encrypted images and inline them for viewing.
Thats the plan! We will probably add a setting somewhere to disable auto-download though.
Reacted by afriedmanGlacierReacted by LAnd if there's any possibility (I read something about iOS not allowing ANY non-https-connection anymore), also allow non-secure http file upload, as per their spec:
- Be as easy to implement as possible. This is grounded on the idea that most programming languages already have HTTP libraries available.
(E.g. Conversations seems to OMEMO-encode files already for encrypted chats.)
And please also allow self-signed certificates after confirmation.
We will not ever allow non-https connections. We do have support for self-signed certs for the XMPP connection but will probably not initially support self-signed http upload servers.
Reacted by Markus BirthFair enough. As long as you keep the self-signed thing on your radar. (Because that's what Gajim's plugin and Monal are failing at currently.)
Reacted by LThats the plan! We will probably add a setting somewhere to disable auto-download though.
That would be a good idea, I should actually go see if Conversations has something like that for httpupload too. I'm mainly on Android, but I have a few users on iOS, and not having httpupload in any manner for them has been very frustrating.
You guys are awesome.
That would be a good idea, I should actually go see if Conversations has something like that for httpupload too.
In Conversations you can set the 'Auto accept file size' to Never to disable that. This will also disable Jingle File Transfer but that's justified because Jingle File Transfer has similar security concerns.
FWIW the current HTTP Upload XEP has TLS as a MUST. So Conversations will probably at some point also disallow non encrypted uploads.
FWIW the current HTTP Upload XEP has TLS as a MUST. So Conversations will probably at some point also disallow non encrypted uploads.
Thanks for the hint. Another reason to add some sort of LetsEncrypt ACME client into eJabberd/Prosody.
Another reason to add some sort of LetsEncrypt ACME client into eJabberd/Prosody.
@mbirth That would be amazing!
@chrisballinger Feel free to give me a 👍 over at processone/ejabberd#1503
@mbirth So would this mean that http_upload would need EITHER TLS OR OMEMO/OTR/PGP, or just require TLS?
An OMEMO encrypted file has different implications than a TLS encrypted one.
So would this mean that http_upload would need EITHER TLS OR OMEMO/OTR/PGP, or just require TLS?
@Semperverus It easy to overlook, but as @iNPUTmice said, the XEP-0363 explicitly says:
The host MUST provide Transport Layer Security.
So it's always TLS and OMEMO/OTR/PGP comes on top of that (optionally).
@mbirth I should probably rephrase the question, as that's not quite what I meant. I should have asked, "are you planning on making http_upload require OMEMO/OTR/PGP encryption in order to work at all".
@Semperverus Oh, I'm not involved in the development of any of the mentioned apps. I'm just a user. And as that, I sure hope http_upload stays "as easy to implement as possible." That means: TLS required, OMEMO/OTR/PGP optional.
Initially we will only be supporting AES-GCM encrypted http transfers, and requiring OMEMO or OTR to exchange the URL and key.
@chrisballinger So sending files via XEP-0363 will only be possible when using OMEMO or OTR?
I use neither OMEMO nor OTR on my own small family XMPP server and I don't want to start using it just to be able to send files.
It's my own server and I really don't need and don't want any encryption here.
And I don't want to be forced to have one.Reacted by L@tmolitor-stud-tu Good point, there's no technical reason to limit it to E2E sessions. Up until now, transfers have only worked within OTR sessions, so I'm thinking that by default it should act similarly. A simple solution would be use plain transfers only if there's never been an E2E session, or when you've forced plaintext sessions.
@iNPUTmice I'm curious how many clients that support 0363 also support the aesgcm spec, and if it makes sense to use that scheme regardless of E2E support to help protect the data at rest.
Reacted by L@chrisballinger Your simple solution sounds reasonable to me and would be enough in my case :)
I'd love to see HTTP uploads in ChatSecure as well, at best with (optional) inline previews of photos and maybe even other media. That would be a huge step towards making ChatSecure more prominent to non-tech-savy users who expect features like this to work 😄
How is the progress in this matter (on the way to 4.1)?
Guys why chatsecure died ?
Seems no more support
anyone can help to find some way to find source code of Zom work well
Maybe a nice idea to add this to ChatSecure? For things like image uploading :)