#2503 Two-tier configuration and trigger system

This FR is continuation of almost 3 years old FR.

KeePass current trigger system has severe drawbacks, first of all in security. Triggers looks like an afterthought. I understand the desire to keep kdbx database format portability and base functionality across all devices and OS's, so trigger system had not affected inner kdbx native format yet. But there is the price to pay for it. Such
an afterthought implementation makes not a lot of sense in terms of security, extensibility and manageability. The design flaws are obvious:

• The majority of use cases makes trigges system business logic to rely tightly on active database scope thus indeed required access to its field references. But as triggers are maintained outside of db itself, they are plain open to any observer having file read level access to the system! Also, although db could be syncronized, any changes in triggers logic aren't portable due to external hosting in configuration file. I think it's time to re-implement. My proposition to dev team follows below.

Two-tier implementation. Not only for the trigger system, but also for the entire configuration system!
Means we have outer config for KeePass (the current one, BTW it should have new hardened defaults to prevent metadata leaks!), where users have usual UI customization stuff etc. AND also inter-db (outer) trigger system for general program automation tasks (as it currently implemented). But, with the second inner (and optional) tier or scope that inherits (like in OOP) and overrides outer config and trigger system when a db just becomes ready to render (BTW delay-able or cancellable when false returned from afterAuthorization() event handler after successful authorization.

What advantages the proposed design brings?

1. Stronger security by encapsulating most sensitive metadata (including db-specific triggers and config settings) inside encrypted db.
2. Greater portability and maintainability with much more flexibility in business logic partitioning. General KeePass built-in handlers would allow execution of custom commands / scripts and provide access to fields like OS environment variables to inner scope triggers. In-db triggers would be able to subscribe to general actions carried by outer KeePass layer (like on db/app/system open and close) with custom db-dependent secure and zero-effort syncable code within db, and fire db-specific events back to outer tier, so it would be bi-directional. Imagine you never need to copy/paste your triggers between many installations/users anymore, that means extreme robustness and portability of once designed and tested automation logic that would be synchronized by design!

What does it bring to configuration?
In the most common use case when working with just a single db, that may bring KeePass UI customizations like adding relevant for the active db custom toolbar buttons (current) and status labels, dropdown boxes etc. (new), menu items or even custom toolbars (all new). Sure the simplest UI changes would be easy applied like enlarging the main window size and on screen position, columns customizations etc. upon db opening/activating/closing as well. And of course, all that metadata like button captions would be securely encrypted within db file!

Isn't that The awesome concept to implement ASAP?

[Paul]

But as triggers are maintained outside of db itself, they are plain open to any observer having file read level access to the system!

If a bad actor can do this it is no longer your computer - law 1 of computer security.

Stronger security by encapsulating most sensitive metadata

Metadata is not meant to be secure. That's why you can use database fields in triggers.
The database is the secure section, anything else is obfuscation and that is not security.

Greater portability and maintainability

I think it would be harder to maintain as you need to remember which config is inside/outside.

Imagine you never need to copy/paste your triggers between many installations/users anymore

This is not the user market for KeePass - its a personal password manager. Implementing this for the few who use it is a lot of effort for very little gain from our development team of one part time programmer.

cheers, Paul

[Anonymous]

Paul, let me address most of your concerns. Except for the almost maintenance mode due to underpowered dev team.

1. A bit of contradiction re bad actor having read access. Maybe we should store our sensitive data in a regular compact unencrypted database, or even in a text file then? Why bother to have a more secure container like kdbx at all? Exactly because the security is multi-layered concept - there are chained and stacked levels of it. Example: having full disk on-the-fly encryption for your OS doesn't protect when you are logged in. Even if computer is still yours :)
2. Metadata protection is essential part of IT security. Why use more secure messengers instead of email? Why to protect TypeGuid of triggers in config file? Why dynamic enlisting plugins compatibility in config gives a clue about a particular KeePass installation and what kdbx may try to do?
3. As you mentioned, KeePass is personal password manager. Agreed. So the vast majority wouldn't ever need a second kdbx to handle. Means never triggers outside that kdbx! And even if you'd need outside triggers, it would be dictated by the app handling logic, not specific database case. That called partition of business logic and helps clarity of implementation and maintainability in the long run.

Hope you'll reconsider.

[Paul]

I'm not the developer, just pointing out there are arguments against doing what you suggest.

cheers, Paul

[Anonymous]

Well, maybe someone else would...