Repository navigation
Conversation
Comment about expiration dates is removed, we will take expiration dates into account when we start merging subkeys.
|
This is just to close old issue, I think we should not merge this until 2.47 and follow-up bugfix releases are out. |
| .signatures | ||
| .iter() | ||
| .any(|signature| signature.key_flags().encrypt_comms()) | ||
| }) |
There was a problem hiding this comment.
I'm wondering, if all the subkeys are expired, will this mean that the receiver is not able to decrypt messages anymore all of a sudden?
For many years, we were on the position of "if the key is expired, just use it anyways, there is nothing better we can do". Maybe we should extend the logic to use expired subkeys if there is no non-expired subkey?
There was a problem hiding this comment.
I added a test in #8744 that makes sure we fail to select any subkey in case there is only an expired subkey.
I don't think we should encrypt to expired subkeys. Expired subkeys should be deleted by the receiver, so this may as well result in undecipherable message, we cannot assume that receiver keeps the key forever. So not being able to send a message may be better than sending it to expired subkey.
Having only one expired subkey is a common problem with GPG because it by default offers the user to create a single subkey that expires in 2 years. Then for 2 years everything works and after 2 years encryption suddenly breaks and it was somewhat ok to ignore the expiration and just send to expired subkey instead of not encrypting.
For Autocrypt2 we are going to make sure that there is always a non-expiring subkey, so we will not have this problem anyway.
|
Replaced with #8744, i will also test the case of having only expired subkeys there. |
2 participants
Comment about expiration dates is removed,
we will take expiration dates into account when we start merging subkeys.
Closes #6520