Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Trusted mode in Kate was a bit of a special code only applied to dialogs, but the intention has always been to help people understand if the screen they were looking at and interacting with came from a trusted source (e.g.: the Kate OS itself), or belonged to an untrusted cartridge. The primary motivation for this is to prevent things like phishing attacks.
E.g.: imagine you're doing something on your regular operating system in a random application. You click a button, which then shows an OS dialog to you asking you to provide administrator rights by typing in your password so that some action can be finished. There's usually not much of a way of knowing where this dialog comes from because it has no distinctive indication that is impossible to mimic from a regular application. You then end up having to trust that the request is reasonable enough to provide your password in this random text input, which will end up god-knows-where. The web improves this slightly by showing you the domain you're currently interacting with on each page (though not always by default on a phone).
When the trusted mode and resource indicators were added to Kate at first, they were meant to address this category of problems. But they weren't quite thought through at the time, as prototyping a usable console was more of a goal, so they ended up being confusing at best. This patch tries to put some principled design behind the idea, while keeping the same goal.
A previous patch had already merged the trusted mode indicator with the resource indicator area, which this patch maintains and builds upon. The new thing in this patch is that every scene (the Kate equivalent of a "window" or "screen" in other operating systems) is branded with an application identifier, which is unforgeable by cartridges. This identifier then allows the OS to know where the currently showing scene originates from. To improve how we communicate this to users, we rely on the fact that Kate only allows one scene to be on foreground at any given time---so we repurpose the resource indicator area to have an indicator of whether the current scene belongs to a trusted application or an untrusted one, similar to how web browsers display a padlock symbol or a different symbol depending on whether the current page is using an encrypted connection or not.
Though this may change in the future if Kate supports multiple foreground processes (not currently planned), the current implementation has a single field to hold the current process and its trust level. The OS scene manager then takes care of updating this field every time the scene it is displaying changes. That makes the whole trust indication consistent throughout the OS---like in web browsers. It also prevents theoretical (and not so theoretical) attacks that were not mitigated by the previous approach, such as a cartridge mimic'ing a regular OS settings screen.
Note that, as a fully capability-based operating system, Kate already mitigates privilege escalation attacks by design. That is, even if a cartridge had managed to acquire a user's password that is used somewhere within the operating system, it would have no way of using that password. HOWEVER, especially when combined with network access, it could always exfiltrate this collected data elsewhere, which would then enable some more indirect attacks. The current implementation closes that gap.