#85 - [User story] - As a user I would like to be able to send new public key after previously sent and confirmed key has been compromised or lost. - Disroot/gpg-lacre - Disroot Forgejo: Brace yourself, merge conflicts ahead.

muppeth commented

2022-06-02 23:34:34 +02:00

Owner

Currently upon new key submission, confirmation email from lacre is sent encrypted to the user as there is a public key for given user. This results in situation where user without access to the key (lost, compromised) cannot confirm email and thus upload new key.

muppeth changed title from ~~[Test feedback] - Unable to upload new key if previous secret key lost~~ to [User story] - As a user I would like to be able to send new public key after previously sent and confirmed key has been compromised or lost.

2022-06-02 23:36:25 +02:00

muppeth added the

FEEDBACK

ISSUE

labels 2022-06-02 23:38:16 +02:00

muppeth commented

2022-06-02 23:55:03 +02:00

Author

Owner

What has been tested:

Uploading new key - results in encrypted confirmation email sent using previously uploaded public key
Uploading blank key - results in encrypted confirmation email sent using previously uploaded public key

Possible solutions:

Not encrypting emails sent from lacre's no-reply address
Using delimiters when sending confirmation to users, if we decide that delimiter emails should not be encrypted (unless we think they should). However there is a pending bug #87

What has been tested: - Uploading new key - results in encrypted confirmation email sent using previously uploaded public key - Uploading blank key - results in encrypted confirmation email sent using previously uploaded public key Possible solutions: - Not encrypting emails sent from lacre's no-reply address - Using delimiters when sending confirmation to users, if we decide that delimiter emails should not be encrypted (unless we think they should). However there is a pending bug #87

muppeth commented

2022-06-03 00:22:55 +02:00

Author

Owner

Giving it a brief moment I think delimiters should always be encrypted to avoid user confusion and to make it easier for lacre (always encrypt).

One extra solution would be to send emails to additional domain eg. plain.lacre.io but that means server operator would have to provide such domain for all users which is too restrictive imo, so one thing would be to make sure no-reply lacre's emails never get piped to lacre?

Giving it a brief moment I think delimiters should always be encrypted to avoid user confusion and to make it easier for lacre (always encrypt). One extra solution would be to send emails to additional domain eg. plain.lacre.io but that means server operator would have to provide such domain for all users which is too restrictive imo, so one thing would be to make sure no-reply lacre's emails never get piped to lacre?

pfm commented

2022-06-06 21:05:20 +02:00

Collaborator

How about letting the user send a revokation certificate?

It could then be imported and therefore could revoke the public key. But of course that only helps when somebody had lost their passphrase, not the whole GnuPG setup / identities.

How about letting the user send a revokation certificate? It could then be imported and therefore could revoke the public key. But of course that only helps when somebody had lost their passphrase, not the whole GnuPG setup / identities.

pfm commented

2022-06-22 20:47:39 +02:00

Collaborator

Another idea: we could accept an additional secret or a backup email that the user could use to revoke the key.

pfm commented

2022-07-14 22:49:56 +02:00

Collaborator

After a brainstorming session, @muppeth and I have decided to encrypt the confirmation email immediately (in front-end code) with the key received from the user.

With this approach, the user doesn't need access to the old key.

Consequence: the user must provide a key they can use to cancel encryption or change the key.

After a brainstorming session, @muppeth and I have decided to encrypt the confirmation email immediately (in front-end code) with the key received from the user. With this approach, the user doesn't need access to the old key. Consequence: the user must provide a key they can use to cancel encryption or change the key.

pfm commented

2022-07-16 12:36:34 +02:00

Collaborator

I had a short chat with a hacker I respect and he said that our solution seemed OK to him.

👍 1

pfm self-assigned this 2023-05-11 21:31:17 +02:00

[User story] - As a user I would like to be able to send new public key after previously sent and confirmed key has been compromised or lost. #85