nextcloud
Missing PGP/MIME support
I have installed and configured mailvelope, authorized the nextcloud domain and enabled the API. On one of my computers yesterday, I saw it working as expected, on the other, I see that incoming PGP encrypted mail (created with Mailvelope) is always displayed only as an attachment, rather than decrypted.
When I access the same mail account through roundcube with mailvelope enable, everything works just fine.
Expected behavior
Tell us what should happen It should just work™
Actual behavior
Mail app
Mail app version: (see apps admin page, e.g. 1.50)
Mailserver or service: self-hosted dovecot
Server configuration
Operating system: (e.g. Ubuntu 20.04)
Web server: Ningx
Database: mariadb
PHP version: 7.4
Nextcloud Version: 20.0.0
Client configuration
Browser: Firefox 81
Operating system: Debian GNU/Linux Bullseye
The problem is that our client can't handle embedded messages. This is not a problem with encrypted messages but any forwarded or similar message that is not the main part.
Ref https://github.com/nextcloud/mail/pull/2541 for the PR that added the download as attachment.
I think there is an existing ticket about the embedded messages but I can't find it right now …
The problem is that our client can't handle embedded messages. This is not a problem with encrypted messages but any forwarded or similar message that is not the main part.
Thanks, Christoph, just what irritates me is, with the same browser and the same Mailvelope it works just fine in Roundcube. I wonder if roundcube has some built-in magic that Nextcloud's mail app does not with regard to Mailvelope support.
Got interested in this because I am in the process of convincing a global human rights network to use Nextcloud and they got unexpectly interested in the mail app, even though they were supposed to use thunderbird with its build-in PGP support... So they definitely need robust PGP handling. Downloading and manually decoding messages is certainly not an option, as most staff and board are non-technical folks...
just what irritates me is, with the same browser and the same Mailvelope it works just fine in Roundcube
It's because Mailvelope just detects the PGP message in the browser document and offers decryption. Nextcloud Mail doesn't display the embedded message at all, hence there is nothing for Mailvelope to detect.
So, again, any simple email with an encrypted emails should work fine. It's just the ones that are send embedded as an attachment.
just what irritates me is, with the same browser and the same Mailvelope it works just fine in Roundcube
It's because Mailvelope just detects the PGP message in the browser document and offers decryption. Nextcloud Mail doesn't display the embedded message at all, hence there is nothing for Mailvelope to detect.
So, again, any simple email with an encrypted emails should work fine. It's just the ones that are send embedded as an attachment. No, unfortunately, in my observation. Simple PGP/MIME messages fail, only legacy inline PGP seems to work.
No, unfortunately, in my observation. Simple PGP/MIME messages fail, only legacy inline PGP seems to work.
Mind exporting such an email as .eml or similar with Thunderbird and posting it here? Then someone can try to reproduce.
Here are the relevant lines:
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted";
boundary="Rfy9LYPuKd9RG8LFoc9aPDXwfzQ32qEQl"
This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)
--Rfy9LYPuKd9RG8LFoc9aPDXwfzQ32qEQl
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification
Version: 1
--Rfy9LYPuKd9RG8LFoc9aPDXwfzQ32qEQl
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"
-----BEGIN PGP MESSAGE-----
wcBMA0AiiRyUAYVDAQf+OUZ3A2Yrpw+EhfFIr00lpkyP6bgrZwoHiolhZvD3zocq9tMRSdDngJg0
gHrgJc91y3jaLSeDuAQUWPU+k4ShevVDM+Z5S2SFwPhRWb5xXj/IANtWPmF4iLjsYSH0tMBpJm/w
But that is a multipart message with a dedicated pgp part. So I guess it's the very same described limitation that Mail can't handle those. If there is a plain text part (as per content type) that contains pgp then it will display, I think.
As a remedy we could always show the application/pgp-encrypted part as if it were text and hope that Mailvelope picks it up.
But that is a multipart message with a dedicated php part. So I guess it's the very same described limitation that Mail can't handle those. If there is a plain text part (as per content type) that contains pgp then it will display, I think.
As a remedy we could always show the
application/pgp-encryptedpart as if it were text and hope that Mailvelope picks it up.
As far as I see it, that's the PGP/Mime standard, which is the default in any real mail client, e.g. Outlook/GpgOL and Thunderbird. Inline PGP seems to be mainly used by Mailvelope and as I understand, it is legacy. PGP/MIME is the correct™ way, that any mailer should support, at least passively.
Just to be sure, this here is from a message composed in Thunderbird 78:
This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)
--siAL4TRdtcJVH51ByjyPKQ6ZH8U234sU2
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification
Version: 1
--siAL4TRdtcJVH51ByjyPKQ6ZH8U234sU2
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"
-----BEGIN PGP MESSAGE-----
wcBMA0AiiRyUAYVDAQf9F77iZuyWvXnXWHJzX1TgqLxj+eu8OZvwkRgJLCIIq/xS98raHnY/Il+P
Sq2pMc6NEKjvAOIPEm/jJPhI09Jt9dtoqMRLEqlAts29XP8YU7vWgCR2So4aPVu9/hRNm6lwfD2s
Thanks for the info! I will look into this when time allows but right now this is a very low priority. If you are a developer or know someone who could help with the development I'm happy to discuss what we might need to change.
Thanks for the info! I will look into this when time allows but right now this is a very low priority. If you are a developer or know someone who could help with the development I'm happy to discuss what we might need to change.
Unfortunately, I am not a developer, my modest contributions to Nextcloud are limited to documentation. However, I should flag that as long as the combo of Nextcloud Mail and Mailvelope cannot handle PGP/MIME messages, it does not implement the established standard, and in my case, this means that it cannot be used by the network as their default mail client, which is a shame because else, they will be using nextcloud for most of their needs.
There is a long-standing Mailvelope bug related to PGP/MIME, https://github.com/mailvelope/mailvelope/issues/41 but I guess that fixing this issue here would not have to wait this other issue be fixed, because all Nextcloud Mail would have to do is download the bodies of messages with the content type "application/pgp-encrypted".
I am interacting with some other organisations who are focused on cybersecurity for civil society and might therefore be interested in contributing, but I would not be optimistic, that they have any free resources to devote to this, unfortunately.
No worries @vasyugan, I appreciate the time you take to report this.
I agree that it's not too much effort. But this is one of many small changes that we have to work on. And everyone has this ticket where they think it's that most important one. But of course that always depends on the user context.
In any case, leaving this open for pickup later or anyone else who would like to help.
Any enterprises using the software can get a subscription and we'll be then able to shift priorities accordingly. But I guess that doesn't work for your organizations.
No worries @vasyugan, I appreciate the time you take to report this.
I agree that it's not too much effort. But this is one of many small changes that we have to work on. And everyone has this ticket where they think it's that most important one. But of course that always depends on the user context.
In any case, leaving this open for pickup later or anyone else who would like to help.
Any enterprises using the software can get a subscription and we'll be then able to shift priorities accordingly. But I guess that doesn't work for your organizations.
Indeed. Civil society networks of that sort have limited resources anyway, and the situation was that I was trying to evangelize them to use PGP and then they discovered that Nextcloud comes with its own mail client which they would prefer to use over Thunderbird, and now I am looking for ways to reconcile security needs with their longing for convenience... I am just worried that they will happily adopt nextcloud but the glaring security of unencrypted e-mail will remain unaddressed.
But that is a multipart message with a dedicated php part. So I guess it's the very same described limitation that Mail can't handle those. If there is a plain text part (as per content type) that contains pgp then it will display, I think.
As a remedy we could always show the
application/pgp-encryptedpart as if it were text and hope that Mailvelope picks it up.
I think that's all that Roundcube does and that indeed suffices to tackle the situation.
@ChristophWurst I just grepped through the roundcube source code for encrypted.asc and application/pgp-encrypted, and it turns out, that it doesn't even have any special code for downloaded and displaying pgp/mime parts. It just seems to honour "Content-Disposition: Inline". Can't Nextcloud Mail just do the same?
It just seems to honour "Content-Disposition: Inline". Can't Nextcloud Mail just do the same?
"just". Yeah …
It just seems to honour "Content-Disposition: Inline". Can't Nextcloud Mail just do the same?
"just". Yeah …
I see that lib/Attachment.php explicitly changes the disposition of mime parts from inline to attachment The comment says: "Serve all files with a content-disposition of "attachment" to prevent Cross-Site Scripting"
So I see, this is a precautionary measure, but it is one that roundcube apparently does not need.
(I thought I coud just make it work by commenting out this line, but this doesn't seem to have been enough)
given that it prevents PGP from functioning properly, it seems to be worth it, exploring alternatives. Again, sadly, I am not a developer, but the task seems relatively limited: ensure that XSS is prevented while content-disposition: inline parts are indeed displayed inline.
Would this be a correct description of the issue?
It's more complex than that. It's not just what part to hide or what not to show. It can become this recursive structure where you have a mesage inside a message inside a message.
This has to be done properly.
So it's blocked until we found the time to work on this or a customer funds the development.
May be a bit late but I just want to clarify something about the PGP/MIME format. A PGP/MIME message just has one attachment, the enrypted message. Once decrypted it contains the message body and all attachments, just like any other non-encrypted message. It even can contain some of the header data like the subject.
The advantage of PGP/Mime over pgp/inline is that it hides the complete content (including file names of attachments) and it keeps all formatting of the message body. See https://tools.ietf.org/html/rfc3156 for details.
And if you like you might want to have a look in the sourcecode of my software https://github.com/gpgmailencrypt/gpgmailencrypt/blob/master/gpgmailencrypt.py#L5001 You simply need to combine the headers of the encrypted email ( escpecially FROM, RECEIVED etc) with the decrypted body. Just the subject needs some additional attention, as it may be part of the encrypted message body (see above)
Technically a mail could contain a pgp/mime attachment and different non-encrypted or pgp-inline encrypted attachments. But this would be totally against the idea of PGP/MIME and I know no e-mail client that can handle such an e-mail correctly.
I believe I have this problem too. I am an new Nextcloud user and I have been trying to get Nextcloud mail and Mailvelope working without success all day. Mailvelope works perfectly with my mail provider's webmail page but doesn't work at all with Nextcloud and mailvelope. All I see is a single attachment "encrypted.asc".
Many mail providers will not switch to inline because as vasyugan mentioned in this thread: https://github.com/nextcloud/mail/issues/3833, PGP/Mime is the standard best practice while inline is a depreciated and not well supported.
If many webmail providers have been seamlessly doing this for years then the problem is not unknown, it is just not supported currently in Nextcloud and Mailvelope.
So it's blocked until we found the time to work on this or a customer funds the development.
I am not an enterprise customer however I may be interested in funding this development. Who do I speak to about this? It is important because without it, Nextcloud and mailvelope mail does not work at all for me.
I am not an enterprise customer however I may be interested in funding this development. Who do I speak to about this? It is important because without it, Nextcloud and mailvelope mail does not work at all for me.
@ioogithub i think one would have to open a bounty for third party developers as nextcloud only works with customers through enterprise subscriptions
https://help.nextcloud.com/c/nextcloud-freelancing/48 is the place to talk about freelance funding. Bounties are a bit of a dated concept right now: https://help.nextcloud.com/t/dont-use-bountysource-anymore/84943
https://help.nextcloud.com/c/nextcloud-freelancing/48 is the place to talk about freelance funding. Bounties are a bit of a dated concept right now: https://help.nextcloud.com/t/dont-use-bountysource-anymore/84943
Thanks! For me, I would have to see where to get external funding for this. There are donors funding cybersecurity related applications, but I would have to go looking. But before that, I guess one should have an idea how much money is actually needed, and also, what the freelancer needs to do to ensure that the patches are accepted by Nextcloud, @ChristophWurst is there any quick read on this? @ioogithub Did I correctly understand you that you might be willing to fund this from your private pocket?
In general I strongly agree with this plan @vasyugan. This week and next I won't have time to look into the details in order to provide any action items or a list of things to change.
In general I strongly agree with this plan @vasyugan. This week and next I won't have time to look into the details in order to provide any action items or a list of things to change.
Do you imply that you will eventually get back to us with a list of changes that would have to be made? That certainly would make the process much easier, as we could specifically tell the freelancer what he needs to change.
So I'll nag you again two weeks from now, I guess.
Am 22.03.21 um 12:55 schrieb Christoph Wurst:
I'll try but I can't promise ✌️
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nextcloud/mail/issues/3833#issuecomment-804005734, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZI4ODU6SGXBCDOGKKXOKDTE4V4RANCNFSM4SU7HZYQ.
@ioogithub Did I correctly understand you that you might be willing to fund this from your private pocket?
Yes I am interested in funding this because without it I can't use Nextcloud Mail and so without it, a cloud platform that can't do email is much less useful.
From the discussion above it sounds like bountysource is no longer a viable option. I contacted Nextcloud sales and although they thanked me for the offer of support they confirmed that they do not accept commissioned feature development.
They also mentioned specifically that this request is not a priority so there is a real risk of funding freelance development work which will not be accepted by the company and integrated into the product for various reasons. Unless I am missing something, it doesn't sound like there is any acceptable mechanisms in place for integrating new features with this funding model.
@ioogithub Did I correctly understand you that you might be willing to fund this from your private pocket?
Yes I am interested in funding this because without it I can't use Nextcloud Mail and so without it, a cloud platform that can't do email is much less useful.
From the discussion above it sounds like bountysource is no longer a viable option. I contacted Nextcloud sales and although they thanked me for the offer of support they confirmed that they do not accept commissioned feature development.
They also mentioned specifically that this request is not a priority so there is a real risk of funding freelance development work which will not be accepted by the company and integrated into the product for various reasons. Unless I am missing something, it doesn't sound like there is any acceptable mechanisms in place for integrating new features with this funding model.
Maybe a viable option would be that a freelancer rather than patching the mail app itself develops the needed additions in form of another app that extends the functionality of the mail app.
Anyway, I think we need to keep nagging @ChristophWurst for directions.
Yes, it is a tragedy that e-mail encryption gets so little love, even from Nextcloud. Unencrypted email in my view is the most glaring security hole. Yes, I agree that for instance Telegram's security model leaves much to be desired, but normal unencrypted e-mail has no security model at all. It is basically as it was 50 years ago.
I'll try but I can't promise
@ChristophWurst Maybe, do you have time now to give us advice?
I'll try but I can't promise ✌️
Hey, @ChristophWurst I thought it was time to poke you again. At present, PGP support is broken, as the one standard, which is state of the art is not supported. If Nextcloud GmbH does not see this as a priority, it would be great if you could give us directions on what we have to to go
- hire a third party to fix it
- ensure that their additions are accepted by Nextcloud Does it make sense to go for a separate app that extends the mail app's functionality?