Change Details

Current color codes: https://dev.gnupg.org/T6869#200682 @ikloecker wrote in https://dev.gnupg.org/T6869#200701: > How to treat not-valid signatures is a topic for long discussions. One view is that there are only two states that one needs to differentiate: The signature is valid (i.e. it is good and the certificate is trusted). The signature is not valid (for some reason) or it couldn't be verified. Another view is that there are three relevant states: valid, invalid, undecidable. > > I'm not sure if using red to indicate danger is a good idea in any case. The most likely reasons for an invalid signature are probably: > > Transmission error, e.g. during message transmission the message was reformatted (this is by far the most common error when using email). > In case of detached signatures: Using a wrong/outdated detached signature to verify a signed file. > > None of those reasons justify putting the user in alarm mode by using the color red. > > Maybe we should use green for valid, white for undecidable (i.e. missing signing certificate), and yellow (or some other non-alarm color) for invalid. > > The current code seems to differentiate the following three states: > > valid signature with valid certificate > signature doesn't match the data > signature with missing, expired or revoked certificate > > I can see why treating expired and revoked certificates the same as a missing certificate can make sense. > > In the end I'm coming back to the two states view: Either the signature is valid or not. Kleopatra cannot know/decide if a not valid signature is a problem and should maybe treat all "not valid" cases (including the "couldn't verify because of missing certificate" case) the same way. > > I'm wondering how we display valid signatures with not certified certificates. Those should probably be white (because there's no problem with signature or certificate, but signatures of uncertified certificates are as good as no signature at all.)

Current color codes: https://dev.gnupg.org/T6869#200682 @ikloecker wrote some thoughts in https://dev.gnupg.org/T6869#200701: Current state of discussion: "Bad signature" (= file was changed) stays red. Valid signature where the certificate is trusted stays green. Currently with white background: Valid signatures (= technically correct) where the signing certificate: a) is expired b) is revoked c) has no trusted certification I was told the background color has been yellow in these cases in the past. Like in Kmail. Why did the color change? And there have been decisions regarding the colors in the past, those should have been documented in the commit messages. Could somebody please check if there is something to be found there? We could maybe think about making the color for an expired certificate less threatening than for "is revoked" or "has no trusted certification". As signatures which were made a log time ago with a recently expired certificate are likely ok. But one has basically to check in all these cases if one wants to trust those signatures, depending on the circumstances. And C) is easy to remedy. Maybe we should explain that case better to the user, but that has nothing to do with color.

Current color codes: https://dev.gnupg.org/T6869#200682 @ikloecker wrote some thoughts in https://dev.gnupg.org/T6869#200701: > How to treat not-valid signatures is a topic for long discussions. One view is that there are only two states that one needs to differentiate: The signature is valid (i.e. it is good and the certificate is trusted). The signature is not valid (for some reason) or it couldn't be verified. Another view is that there are three relevant states: valid, invalid, undecidable. > > I'm not sure if using red to indicate danger is a good idea in any case. The most likely reasons for an invalid signature are probably: > > Transmission error, e.g. during message transmission the message was reformatted (this is by far the most common error when using email). > In case of detached signatures: Using a wrong/outdated detached signature to verify a signed file. > > None of those reasons justify putting the user in alarm mode by using the color red. > > Maybe we should use green for valid, white for undecidable (i.e. missing signing certificate), and yellow (or some other non-alarm color) for invalid. > > The current code seems to differentiate the following three states: > > valid signature with valid certificateCurrent state of discussion: "Bad signature" (= file was changed) stays red. > signature doesn't match the dataValid signature where the certificate is trusted stays green. Currently with white background: Valid signatures (= technically correct) where the signing certificate: > signature with missing,a) is expired or revoked certificatered > > I can see why treating expired andb) is revoked certificates the same as a missing certificate can make sense. > > In the end I'm coming back toc) has no trusted certification I was told the two states view: Either the signature is valid or notbackground color has been yellow in these cases in the past. Kleopatra cannot know/decide if a not valid signature is a problem and should maybe treat all "not valid" cases (including the "couldn't verify because of missing certificate" case) the same way. >Like in Kmail. > I'm wondering how we display valid signatures with not certified certificates. Those should probably be white (because there's no problem with signature or certificate, but signatures of uncertified certificates are as good as no signature at all.)Why did the color change? And there have been decisions regarding the colors in the past, those should have been documented in the commit messages. Could somebody please check if there is something to be found there? We could maybe think about making the color for an expired certificate less threatening than for "is revoked" or "has no trusted certification". As signatures which were made a log time ago with a recently expired certificate are likely ok. But one has basically to check in all these cases if one wants to trust those signatures, depending on the circumstances. And C) is easy to remedy. Maybe we should explain that case better to the user, but that has nothing to do with color.