~rjarry/aerc#6: 
pgp: option to attach signature and public key

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

Status
REPORTED
Submitter
~ghost08
Assigned to
No-one
Submitted
2 months ago
Updated
5 days ago
Labels
feature

~rjarry 2 months ago

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.

~ghost08 2 months ago

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/false and pgp_sign_command.

~jamesponddotco 2 months ago*

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 ¯\(ツ)/¯.

[1] https://lists.sr.ht/~sircmpwn/aerc/patches/14523

[2] https://lists.sr.ht/~sircmpwn/aerc/patches/13861

~rjarry 2 months ago

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.

~ghost08 2 months ago

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.

~rjarry 2 months ago

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.

~jamesponddotco 2 months ago

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.

[1] https://git.sr.ht/~rjarry/aerc/commit/67923707ffd826ad1d02c0a5b5ebd75ffbc71364#commands/compose/send.go

~rjarry closed duplicate ticket ~sircmpwn/aerc2#538 a month ago

~huge a month ago

~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.Reader to Stdin on exec.Command("gpg", "-d") and replaced the io.Reader from pgpmail.Read() with the StdoutPipe() 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 :pipe and 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.

~ghost08 a month ago

Yay! That's huge! Can't wait to try it out :)

~rjarry a month ago

This ticket is fine, thanks for working on this!

~huge a month ago

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?

~rjarry a month ago

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.

~huge a month ago

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.MessageDetails field in the MessageView. 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.

~rjarry a month ago

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.

~huge a month ago

~tristan957 a month ago

For what its worth, https://github.com/ProtonMail/go-crypto is the successor to the golang openpgp package.

Mark a month ago · edit

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.

~konimarti a month ago

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.

~konimarti a month ago*

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.

~jamesponddotco 29 days ago

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.conf would be nice to have. Something like:

[james@cipher.host]
[...]
sign    = true
encrypt = true

~konimarti 27 days ago*

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.conf would 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.

~rjarry 18 days ago

Koni Marti referenced this ticket in commit 69d4e38.

~rjarry 18 days ago

Koni Marti referenced this ticket in commit b19b844.

~rjarry 11 days ago

Koni Marti referenced this ticket in commit 69d4e38.

~rjarry 11 days ago

Koni Marti referenced this ticket in commit b19b844.

~rjarry 10 days ago

Koni Marti referenced this ticket in commit 69d4e38.

~rjarry 10 days ago

Koni Marti referenced this ticket in commit b19b844.

~rjarry 5 days ago

Koni Marti referenced this ticket in commit 69d4e38.

~rjarry 5 days ago

Koni Marti referenced this ticket in commit b19b844.

~rjarry 5 days ago

Koni Marti referenced this ticket in commit 69d4e38.

~rjarry 5 days ago

Koni Marti referenced this ticket in commit b19b844.

~rjarry 5 days ago

Koni Marti referenced this ticket in commit 69d4e38.

~rjarry 5 days ago

Koni Marti referenced this ticket in commit b19b844.

Register here or Log in to comment, or comment via email.