It would be great if there where a option to create the email signature and automatically attach it. And also attach the public key.
This would require some gpg integration although this is already a thing with receiving and verifying signatures (https://lists.sr.ht/~sircmpwn/aerc/%3CC11JC39B2EUP.9Y18EIDU7UMO%40homura%3E)
And if we're at it. Other pgp things would be nice too. Like sending encrypted mails if there is a public key for the address.
I've already started to discuss this here: https://todo.sr.ht/~sircmpwn/aerc2/357
Hi,
could you propose a spec of the commands that are missing? I am not that familiar with pgp and it would be better if this is designed (if not implemented) by someone who uses it on a daily basis.
Thanks.
I'm also no expert on this. I don't use gpg from cli like this. But when I do, I search it in history or on internet.
So I've found how mutt does it: https://gitlab.com/muttmua/mutt/-/blob/master/contrib/gpg.rc
I can take a look at the signing bit, but don't know when it will be ready.
So specifically just
crypt_autosign=true/falseandpgp_sign_command.
An initial patch for signing support exists[1] and works pretty well—I have been using it since Eyal sent it to the old list—, but it needs to be rebased with the current repository. I talked to Eyal about the patch a while ago, and they said Drew had a few things in mind for PGP and thoughts on the patch, but I accidentally deleted the email before replying, so I don't remember what the thoughts were.
There is also a patch to refactor the keystore[2], which might be worth looking into. If someone can get Drew's idea for PGP support on paper, I can try it now that I am playing with Go more frequently. If I can't handle it, at least we will have the design documented for the next person ¯\(ツ)/¯.
I guess the first patch should be fairly easy to rebase on the current master. We can always refine it if we get some insight from Drew.
I'm not a big fan of this separate keyring just for aerc. If you have gpg available and a key generated, that's all you need.
And I think I'm not the only one: https://lists.sr.ht/~sircmpwn/aerc/%3CC11JC39B2EUP.9Y18EIDU7UMO%40homura%3E
I think that the mutt approach is better, more "unix philosophy"-like. aerc is for mails, gpg is for encryption, signing, verification and key management.
This whole key management (https://lists.sr.ht/~sircmpwn/aerc/patches/13861) just makes things more complicated for the user. Now you got to manage all the key things and there would be potentially more things that users would love to do with the keyring.
But that is just me. I'll go with the flow.
I tried rebasing this patch on the current master. I get a lot of conflicts. Some of them are really not trivial. I think this needs to be rewritten.
I agree that I don't like the idea of a separate keyring. Aerc should at least use external gpg commands if a gpg go library is not available.
I tried rebasing this patch on the current master. I get a lot of conflicts. Some of them are really not trivial. I think this needs to be rewritten.
Yeah, I got halfway down but got stuck as well. It looks like the refactor in #67923707[1] makes it easier to rewrite the entire patch—but then again, I am just getting started with Go.
I agree that I don't like the idea of a separate keyring. Aerc should at least use external gpg commands if a gpg go library is not available.
I would rather not have Aerc handle the keyring too. The keystore idea was a requirement from Drew if I remember correctly.
~rjarry: Not sure if I should track this here or make a new ticket. Lemme know and I can create another and you can assign to me.
Made some progress on the proposal I made in https://todo.sr.ht/~sircmpwn/aerc2/538 tonight. Was pretty trivial to get this decrypting msgs properly. Literally just set
fm.Content.Readerto Stdin onexec.Command("gpg", "-d")and replaced theio.Readerfrompgpmail.Read()with theStdoutPipe()from the command. My key is on a smartcard, which is kind of the worst case scenario for /x/crypto/openpgp and now this is working like a champ!It's totally usable now for reading. It feels about twice as fast as mutt displaying the same msgs, so that's something.
My remaining TODOs:
- Implement signing outgoing msgs
- Implement sig verification
- Update config
- Make sure
:pipeand whatever else works with the decrypted output properly- Update the config doc
- Remove any unused code from prior implementation
Will try to make some progress over the weekend.
Yay! That's huge! Can't wait to try it out :)
This ticket is fine, thanks for working on this!
I think I'm going to pull
DecryptKeys()as part of this patch. It's being completely bypassed in the only place it's used (NewMessageStoreView()).
DecryptKeys()is the only opportunity to enter a password for a key from within aerc, but I don't know of a workflow with the system gpg where that would be needed. Generally you'll be prompted by pinentry or whatever you normally use to unlock your key.Any objections here? Does anyone have a workflow I'm not thinking through?
I am OK with this. If we are switching to plain gnupg commands, we might as well go all the way.
By the way, I don't know what your plan is for signature verification. For now, it is "integrated" as part of the message viewer. Meaning that the actual signature is not displayed as a message part. Only the signature verification result is shown below the message common headers. I'm not sure what happens for inline signatures.
Do you think it is possible to preserve the current UX with external gpg commands?
Please try to split your changes in multiple patches if possible.
Thanks.
Do you think it is possible to preserve the current UX with external gpg commands?
The plan is to still try and populate the
openpgp.MessageDetailsfield in theMessageView. If that path is viable then the UI won't change at all.It also seems like encrypted sending and signing isn't currently implemented. Is that the case? If so, maybe I just ship the patch to read and knock out the other TODOs as separate changes.
As far as I know, only the signature verification is supported currently. Yes please send a first patch to allow standard gpg shell commands for signature verification. The rest (encryption, decryption and signing) should be done in separate patches.
WIP patch sent with notes: https://lists.sr.ht/~sircmpwn/aerc/patches/27092
For what its worth, https://github.com/ProtonMail/go-crypto is the successor to the golang openpgp package.
For what its worth, https://github.com/ProtonMail/go-crypto is the successor to the golang openpgp package.
AFAIK it still doesn't support smartcards or any scenario where you can't pass in a full private key. I'd love to be wrong here because I've been trying to add smartcard signing to a go-git application and hit the same wall with protonmail/go-crypto and protonmail/gopenpgp.
I've worked on a simple gpg implementation for fully encrypted outgoing email messages along similar lines as discussed above: relying on gpg for the key management and using a gpg shell command. A patch that demonstrates the idea is on the way. However, I would also prefer using a proper go gpg package if available but haven't looked into this yet.
Hi guys, as mentioned above, I have been working on this PGP topic recently and submitted a patch today: https://lists.sr.ht/~rjarry/aerc-devel/patches/27588
It implements PGP encryption and signing of the outgoing emails with the go-pgpmail package (v0.2.0). This is basically the same package that is used for the signature verification part in the message viewer.
For what its worth, https://github.com/ProtonMail/go-crypto is the successor to the golang openpgp package.
I have replaced the golang/x/crypot package with the ProtonMail fork consistently.
WIP patch sent with notes: https://lists.sr.ht/~sircmpwn/aerc/patches/27092
In this patch I also relied on the current logic of the keystore which deviates from the approach in patch #27092 with the external gpg commands.
The downside of the internal keystore is certainly the synchronization issue (i.e. one has to regularly run gpg --export and gpg --export-secret-keys in order to have an updated keyring in aerc).
Let me know if this patch goes in the right direction or not. Feedback is welcome.
Hi guys, as mentioned above, I have been working on this PGP topic recently and submitted a patch today: https://lists.sr.ht/~rjarry/aerc-devel/patches/27588
Awesome job, ~konimarti!
I have been using and testing this patch for a few days now, and everything works as expected. It would be nice to get other people's input, though, as I mainly use the signing function.
The downside of the internal keystore is certainly the synchronization issue (i.e. one has to regularly run gpg --export and gpg --export-secret-keys in order to have an updated keyring in aerc).
As a temporary workaround, while integration with the local keyring is not available, we could include a flag for the aerc command that synchronizes the internal keystore with the keyring from GPG. However, I think a simple shell script inside the
/contrib/directory might be a better idea.Feedback is welcome.
The ability to configure signing or encryption by default using
accounts.confwould be nice to have. Something like:[james@cipher.host] [...] sign = true encrypt = true
Awesome job, ~konimarti!
Thanks! Happy to get your thoughts and feedback on this.
As a temporary workaround, while integration with the local keyring is not available, we could include a flag for the aerc command that synchronizes the internal keystore with the keyring from GPG. However, I think a simple shell script inside the
/contrib/directory might be a better idea.+1 for the shell script idea in contrib. This keeps it simple and easy to setup for people who would like to use it with current keyring implementation.
The ability to configure signing or encryption by default using
accounts.confwould be nice to have. Something like:[james@cipher.host] [...] sign = true encrypt = true
This could also be a topic for a next patch together with the shell script above.
Koni Marti referenced this ticket in commit 69d4e38.
Koni Marti referenced this ticket in commit b19b844.
Koni Marti referenced this ticket in commit 69d4e38.
Koni Marti referenced this ticket in commit b19b844.
Koni Marti referenced this ticket in commit 69d4e38.
Koni Marti referenced this ticket in commit b19b844.
Koni Marti referenced this ticket in commit 69d4e38.
Koni Marti referenced this ticket in commit b19b844.
Koni Marti referenced this ticket in commit 69d4e38.
Koni Marti referenced this ticket in commit b19b844.
Koni Marti referenced this ticket in commit 69d4e38.
Koni Marti referenced this ticket in commit b19b844.
Thanks for rewriting my patches, ~konimarti! I'm quite excited to finally be able to update aerc.
As for dropping the internal keystore, I'd really prefer not to do that, because I think it'll make implementing the rest of the PGP functionality in a seamless way a lot harder. I'm not really sure what to do about smartcard support, but I feel like it should be possible to implement it in go-crypto.
Here's the brain dump I got from Drew a while ago:
After reading that gemini link I agree with it. As a simple user of aerc that doesn't fiddle with pgp much, it would make my life and others like me, much easier.
For those without a gemini client, here's the content:
Drew DeVault wrote:
Goal is to make using PGP effortless. The typical user with no knowledge of PGP should be able to set up and use PGP securely.
Composition:
The submission page should display the PGP status of the outgoing email. All emails should be signed, regardless of if a key is available at the destination. If a key is available, opportunistic encryption should be used. We should also attach our public key to all signed or encrypted emails, to facilitate TOFU.
An option should be added which, for encrypted emails, moves the To, From, Cc, and Subject headers into an application/rfc2822 attachment, which is then encrypted. The affected headers in the top-level email should be updated to generic headers, such as Subject: Encrypted email.
aerc should automatically detect emails formatted in this way, automatically decrypt them, and use the embedded message's headers for display in the UI.
Message view:
If a PGP key is attached to an email, we should offer to import it into the trust store. A TOFU config option should be added which would allow this to be done without user confirmation. If an email is encrypted for our key and signed with a key in the key store, we should add a flag to the key which notes that the receipient already has our public key, in which case we can skip attaching it to emails sent to them.
Key management:
We should set up a new UI for browsing the key store, which should list public and private keys and allow you to manage importing/exporting/deletion/etc.
Account wizard:
Should offer to generate a PGP key or to import them from GPG if present. The GPG public keyring should also be imported if present.
New commands:
- Generating private keys
- Importing or exporting keys
- Removing keys
The pipe and save commands should grow flags for choosing whether to pipe the original, encrypted message, or the decrypted message.
While working on something else for work, I started thinking about a secret store for aerc to store credentials securely by default, instead of defaulting to saving passwords in plaintext.
I bring this up because the secret store could be used to store keys exported from PGP as well, which could alleviate some concerns raised by users in this thread. At the same time, I am not sure entirely sold on the threat model.
As far as the implementation goes, initially I thought about using native OS keyrings, like KeyCtl or Secret Service on Linux, Keychain on macOS, and Windows Credential Manager on Windows. However, since I do not have Windows or macOS machines, I can't test the implementation on them.
So, instead, I thought about using a key-value store that uses a single file like bbolt[1] as a database, and then encrypting the file with AES GCM or Go's NaCl Secretbox module using a user-provided password. Since I would be using Golang's standard library, the issues of the first idea would not be a problem.
Is this something that would be accepted and maybe solve some issues raised in this thread and others? I realize this feature may be out of the scope of an email client, but then again, we could say the same about a key store.
I can start working on it this weekend, and perhaps have a patch ready for review next week.
Koni Marti referenced this ticket in commit 69d4e38.
Koni Marti referenced this ticket in commit b19b844.
I think this one can be considered complete.
Great job guys :)