This is just gibberish. The dialog may as well say "blah blah blah"
To be understandable, it would have to be something like:
Title: "Do you trust Livna.org?"
Content: "You are trying to install software provided by Livna.org.
If you don't trust Livna.org, then click Cancel."
Buttons: [Cancel] [Install from Livna.org]
Don't know about the exact wording, but the point is to make it understandable you must be able to say "from Livna.org" not "has fingerprint [ridiculous hex number]"
Implication: you must have a key from Livna signed by a key you already trust. More specifically the key you already trust should be used to certify that the string "Livna.org" accurately describes the new key.
If you don't have the chain of trust, then the dialog is pure programmer ass-covering bullshit, with no actual security function, because it's simply not possible to make it understandable through any kind of rewording (of course, since it's an interruption, people won't read it even if it is understandable).
Owen makes the good point that for security you want to *get the dialog out of the workflow*. That is, importing a key should not be possible "inline" when you go to install a package. It should be something you have to take explicit action to do.
The reason is that then the task you're doing is "import a key," which means you'll think about the dialog and whether a key should be imported.
If you *interrupt* the task "install a package," people will just always click yes. Any dialog that *interrupts* cannot possibly add much security, because of the way people's brains work - they are thinking about their goal, not the interruption.
All these dialogs do is allow blaming people when they get hacked, they don't genuinely keep people from getting hacked. Presumably the goal is that if I admin a bunch of systems, I'm not fixing viruses on them all the time. That means my goal is *in practice* people aren't getting hacked. It's a small comfort if I can *blame the users* when they get hacked. Maybe satisfying in a way, but not really ideal.
To truly get rid of the dialog, you need to go beyond having a trusted key certify that the new key is correctly named "Livna.org" and have the trusted key also certify that Livna.org is trustworthy. Then you don't need a dialog at all. You would of course need some political process for determining "trustworthy repos according to XYZ," but each distribution and each local site can have their own process and their own "bootstrap keys" that they install. So it isn't really centralized, it's controlled by whoever admins the system. Admins may choose to add root keys from a project like Fedora, or they may only choose to allow repos that they have personally signed with their own site-local key.
If a crappy dialog is unavoidable, do at least make it about 1/3 the amount of text in this mockup... should be maybe two lines total, not five lines of text plus a 5-line mysterious table.
I'm not sure how one verifies a key (see how useless the dialog is, even to programmers?) but if say the way you verify a key is to check that at http://rpm.livna.org
you can find the number BB7576AC, you could make the dialog say:
"Does the number BB7576AC appear at http://rpm.livna.org
Which at least tells me what to do.
(I just went to rpm.livna.org and can't find anything about their keys, so I guess the above is wrong, but you see the point that it should just tell me what to check and where.)
(But still, the best solution is that there's no dialog if some key I already have has certified the repo I'm adding, indicating that the repo is approved by someone I trust, whether a project or a local admin.)