The user should be able to upload and delete his public key
The test email in settings/admin/additional, should be send encrypted if the key was uploaded and signed if there is a server private key
Maybe working?
Creating server Keys on install/update
What to test?
Check if Server Keys are generated
Check the log for:
“Saved server key fingerprint:”.$fingerprint." to system config"
“No server GPG key found so no signed emails are possible”
I totally like the idea of encrypted mails send by the server, but do I get this right, that I need to install nextcloud from your repository and am cut off from the Nextcloud GmbH repository?
In that case I would prefer an app, that brings the additional features, instead of a fork.
At the moment it is under devolpment and not ready for production. In the end I would like to get it integrated into Nextcloud maybe at version 14.
This implementation extends the mailsystem with an extra parameter if and to whom the email should be encrypted. This parameter has to be set by the part of nextcloud creating the email. (For example the share by email dialog or the part creating the test email for the email configuration.) This part has a lot of information (user requested the sending, meaning of the content of the email) on wich it can decied if the email is encrypted.
In worst case it could ask the user if the email should be encrypted. For example the “share by email” dialog could be extended with an option encrypt email with gpg.
To get this with an app, the app would have to interact with all this parts of nextcloud, where emails are created. I think it is not possible to implement it, but maybe I’m wrong here.
The second Implementation could be an app which gets all emails bevor they are sent. But then the app is lagging alot of information. It could for example decied based on the reciver of the email if it is encrypted or not. But this would mean that every email where a public key of the reciver is known to the app would be encrypted. But imagen an instance with two users Alice and Bob. And both know Charlie. Alice and Charlie are encryption affine and exchange Public key’s. Alice imports the key into her contact of Charlie. Then Bob shares a file with Charlie via email. The app gets an email from Nextcloud to charlie. And the app know’s a public key for charlie. So the app is going to encrypt the email for charlie. So in the end Charlie would get an encrypted email from Bob. This would be an unexpected behavior. And it would get more messedup if Chalie gives different Public keys to Alice and Bob.
The Mailingsystem in Nextcloud is as far I noticed disconnected from the Mail app.
So on the first step I would like to get the gpg class and the mailing system to use it.
The second step would be from my point of view, to enable GPG key upload on contacts to encrypt share by Email messages. The third step would be an app for the Key management.
After that I have some Ideas to get GPG email working in the mail app, or an own app, but it is just an Idea.
The main Problem is, that you could do the encryption serverside-> then a admin would be able to get your key.
Or on the client as javascript-> there is an app which does it, but the key are on the client, which is maybe a bad idea, when sitting in an internetcoffee. And probably you don’t want to install an app every time, you want to check your emails.
Today I had the Idea, that it would be possible to splitt the key into two parts, since RSA is mostly a modluar power operation. This way the javascript cloud do the fist step of the encryption and the server the second part, but no system would get the full private key. But I have to think about, if it is a good Idea to splitt the RSA algorithm and how many side channel attacks this would allow.
Thanks for making that GPG app. I am interested in protecting email notifications sent from the calendar plugin… Is it possible to add the php-gnupg module into NC23 snap ?
NC23 Snap is not installed with phpx.x-gnupg which is required by the app
I think this is a disadvantage of Snap.
But perhaps you can create an issue.
GPX Mailer is also only supported till Nextcloud 21.
I think this feature is not really useful.
System messages should minimal and without confidential content.
All confidential infos should be behind a Nextcloud link with user authentication and TLS/SSL.
We send calendar item notifications by email. Some of the calendar items are financial and can be a bit to descriptive for plain text email communications. The GPG plug in would be a good solution. On wordpress upload notifications are emailed, the messages are GPG then sent.
Do you have a bare metal install of NextCloud that enables a /snap/bin/nextcloud.occ app:enable --force gpxmailer command to be run to force install to test NC23 compatibility ?
I have avoided the bare metal installs as I like to get the latest versions. When the snap is updated i dont see data loss; i heard it is difficult to port data from the db to a new bare metal install.
I think e-mails for inital passwords and reset passwords are ok. If a hacker uses it the normal user get information of it because the old password does not work. I think it is actually only a risk to send the current password, which you do not change.
I do not know the really reason for this thread anymore. But if you need passwords for public shares (links for no real users) look the app Guests. If you use guests you can also leave the problem with the passwords for temporal users.
gpgmailer automatically becomes disabled even if the --force flag is set. There doesn’t seem to be a straightforward method to enable it in NC23 or NC24.
However, if you have shell and root access to the server, you may be able to use GNU Anubis to encrypt emails once they hit the smtp process…
Current large email provider policies do the following:
Provide unauthenticated TLS cover (aka opportunistic TLS) for server to server communications
Sign all mail using DKIM keys
Check DKIM signatures upon receipt
Check SPF records for spoofing
Given the above list, if one is using a reputable email provider or properly configured self-run service, password reset emails or other general system admin type emails should be perfectly safe even if a malicious actor attempts to use the “reset password” function to compromise an account. However, two factor can also be setup for this purpose.
Having written that… I firmly disagree that encrypting outgoing server emails is not a useful feature. There are certainly plenty of valid use cases.
What is the reason for limiting the gpgmailer app to lower unsupported NC versions? The gpg functions in PHP7.4 seem to work just fine…
I looked at App GPG Mailer and it is supported till Nextcloud 23 but not Nextcloud 24. I think it is a developer problem. You can read this issue or comment it. It seems to work with Nextcloud 24, too.
But i think 99% of all users are not intested in GPG encrypted emails. For Nextcloud and the rest of the internet. As i wrote above i think encrypted emails are not so relevant for initial and reset passwords if they are set with HTTPS direct in the Nextcloud after email.