[RFC] Use color to warn about invalid/untrusted signatures

[lucc]

This is a proof of concept that I hope to develop further if you like the idea. Questions for discussion:

• do we want colors?
  • do we fix them?
    • green = good & red = bad or
    • default = good & red = bad
  • yet another config/theming option

Also I am trying to write tests for this in order to better understand when and what should be indicated but I will come up with some questions about the tests for sure (@dcbaker I am looking at you ;)

[lucc]

The commit bd7fc27 for example contains 2 expected failures where I don't understand why the mock.patch doesn't work.

[dcbaker]

This is your problem. The mantra you need when using mock is "mock it where you use it", so in this case what you actually want to patch is 'alot.settings.utils.AttrSpec'.

the long version of this is that python makes a shallow copy to prevent people doing stupid things from affecting other people by doing a shallow copy of imports into your module.

[dcbaker]

I've definatly hit that before and spent a lot of time scratching my head ;)

[lucc]

Thank you!
I will embrace the mantra 🙏 although I didn't get the technical background yet.

[dcbaker]

so, when you do an import, you get a shallow copy (a group of pointers basically) back to the original module. That way if someone does something stupid in their packge like:

import os

os.path.join = lambda *a: '/'.join('foo', *a)

then that doesn't propegate out of their module. So even if that module is imported into your module and then you import os, you'll get a new shallow copy of the canoncial os module.

[lucc]

Ahh now I get what you mean.

[dcbaker]

Questions for discussion ...

I personally like the idea of using green for trusted, red for invalid, and default for unkown, although letting the theme set the values might be smarter.

The thing is, that there are 4 states of gpg signatures:

1. I have the key, and I've verified that the signature is valid, and I trust it
2. I have the key, and I've verified that the signature is valid, but the key has insuffcient trust
3. I don't have the key
4. I have the key, and either the signature is invalid (or the key expired), or I distrust the key

I don't know what's best. I think I'd be okay with using default for 2 & 3, but I really want to be warned in the case of 4

[pazz]

FWIW, my thoughs on this:
in the above list, I think it is reasonable to group 2 and 3 together as "something's not quite right", and colour this orange by default.

Hardcoding the colouring is maybe not the greatest idea, although most people will stick to the defaults of green/orange/red, simply because someone might have an awkward colour theme for the terminal (all red?) and will want to change the alot theme accordingly.

I'd be happy with a pseudo header, but a possible alternative would be to amend the "summary line" of messages to include some text-tag or so, and theme those summary lines similar to the threadline's in search buffers:

For instance, here is part of a theme file:

...
[thread]
    attachment = 'default','default','%(16_base00)s','%(16_base3)s','%(256_base00)s','%(256_base3)s'
    attachment_focus = 'underline','default','%(16_base2)s','%(16_yellow)s','%(256_base2)s','%(256_yellow)s'
    body = 'default','default','%(16_base00)s','%(16_base3)s','%(256_base00)s','%(256_base3)s'
    body_focus = 'default','default','%(16_base00)s','%(16_base3)s','%(256_base00)s','%(256_base2)s'
    arrow_bars = 'default','default','%(16_yellow)s','%(16_base3)s','%(256_yellow)s','%(256_base3)s'
    arrow_heads = 'default','default','%(16_yellow)s','%(16_base3)s','%(256_yellow)s','%(256_base3)s'
    header = 'default','default','%(16_base00)s','%(16_base2)s','%(256_base00)s','%(256_base2)s'
    header_key = 'default','default','%(16_magenta)s','%(16_base2)s','%(256_magenta)s','%(256_base2)s'
    header_value = 'default','default','%(16_blue)s','%(16_base2)s','%(256_blue)s','%(256_base2)s'
    [[summary]]
        even = 'default','default','%(16_base00)s','%(16_base2)s','%(256_base00)s','%(256_base2)s'
        focus = 'standout','default','%(16_base3)s','%(16_yellow)s','%(256_base3)s','%(256_yellow)s'
        odd = 'default','default','%(16_base00)s','%(16_base3)s','%(256_base00)s','%(256_base3)s'
[search]
    [[threadline]]
        normal = 'default','default','%(16_base01)s','%(16_base3)s','%(256_base01)s','%(256_base3)s'
        focus = 'standout','default','%(16_base2)s','%(16_yellow)s','%(256_base2)s','%(256_yellow)s'
        parts = date,mailcount,tags,authors,subject
        [[[date]]]
            normal = 'default','default','%(16_base01)s','%(16_base3)s','%(256_base01)s','%(256_base3)s'
            focus = 'standout','default','%(16_base3)s','%(16_yellow)s','%(256_base3)s','%(256_yellow)s'
        [[[mailcount]]]
            normal = 'default','default','%(16_base01)s','%(16_base3)s','%(256_base01)s','%(256_base3)s'
            focus = 'standout','default','%(16_base2)s','%(16_yellow)s','%(256_base2)s','%(256_yellow)s'
        [[[tags]]]
            normal = 'bold','default','%(16_yellow)s','%(16_base3)s','%(256_yellow)s','%(256_base3)s'
            focus = 'standout','default','%(16_base3)s','%(16_yellow)s','%(256_base3)s','%(256_yellow)s'
        [[[authors]]]
            normal = 'default,underline','default','%(16_blue)s','%(16_base3)s','%(256_blue)s','%(256_base3)s'
            focus = 'standout','default','%(16_base2)s','%(16_yellow)s','%(256_base2)s','%(256_yellow)s'
            width = 'fit',0,30
        [[[subject]]]
            normal = 'default','default','%(16_base00)s','%(16_base3)s','%(256_base00)s','%(256_base3)s'
            focus = 'standout','default','%(16_base3)s','%(16_yellow)s','%(256_base3)s','%(256_yellow)s'
            width = 'weight',1
        [[[content]]]
            normal = 'default','default','%(16_base1)s','%(16_base3)s','%(256_base1)s','%(256_base3)s'
            focus = 'standout','default','%(16_base2)s','%(16_yellow)s','%(256_base2)s','%(256_yellow)s'
...

So, we could use, say options thread.summary.parts to specify the bits to be displayed in the message summary (with the individual parts defined in subsections).
One of those parts could be "gpg-status", for instance.

Just a proposition, this might be overkill..

[dcbaker]

Where are we at with this feature? Do we just need someone to sit down and do a through review?

[lucc]

@dcbaker I consider this "stalled" currently. I am not very motivated at the moment to push it forward but here are the relevant points I think.

We need to

• implement the new theme option/attribute (I assume we follow pazz's argument), currently "global.notify_error" is used
• decide if we want to keep the color/info in a pseudo header or move it to the summary line
• decide what possible different statuses we want to highlight (I would say 1. in [RFC] Use color to warn about invalid/untrusted signatures #1025 (comment) is the only "good" thing, an invalid sig or an insufficiently trusted key are both "bad", I am undecided if not having a key is "bad" or "neutral", also see below)
• do we only highlight "bad" in some negative colour (red) and keep "good" in the default color or do we highlight it positivly (green)?
• more tests? (well we can always have more tests)

Idea for another PR: If we don't have the key we can try to fetch it in the background and update the ui when it is available.