#2239 Opened active (in focus, or last selected) database triggers scope

For security, functional portability and ease of syncing reasons, I'd suggest introducing opened DB scope for triggers. That way they would securely stored inside encrypted kdbx file, thus seameless integration would be achieved on db sync. As the bare initial minimum, most of the current KeePass app scope wide trigger functionality specifically related to database events (like db opened after successful decryption, hasChanges, beforeDbClosing) may be cloned or even moved into the proposed scope.

[Paul]

Adding triggers to the database doesn't increase security because you would still need triggers outside the database. It's useful for portability but you can just copy your config file with your database.

cheers, Paul

[Anonymous]

Could you please be a bit more specific in regard of what triggers outside kdbx needed for instance when syncronizing databases with remote location? Besides, as per subject, I specifically asked for introducing a NEW scope, not REPLACING the existing global one.

As per attaching config file or just text of triggers into db entries, I already do that, but that is not a convinient way to do it as you'll have to remember to MANUALLY update those after every single change in triggers.

[Paul]

If you don't replace the existing triggers you gain no security.

Your suggestion about portability is sensible. What may work is having a special entry(ies) containing triggers that KeePass uses in addition to any contained in the config file.

cheers, Paul

[Anonymous]

To make myself clearer, the only currently working and partly secure (credentials to remote connection and remote kdbx path and file name are protected inside kdbx entry) solution implemented for now utilises the techique described here. Integrating syncronization triggers OnDbOpened+OnDbClosing (database scope wide as proposed in the first post) completely inside kdbx file will eliminate any traces of remote synchronization from machine config completely. That's the extra security benefit I'd mentioned. Portability and robustness (no need to manually sync changes between machine configs as the functionality would be built-in) are the another two advantages.