You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently in case of SS architecture the first attachment which passed correct dbcrypt key works as unlocker for all further attachments - database key on SS is shared among all attachments using same DBB. In some cases (distributed encrypted databases) such behavior is highly undesired. Initially I've supposed that all functionality related with reject of key-less attachments may be implemented by KeyHolder plugin. Unfortunately such plugin in many cases can't efficiently distinguish between bad and correct key, provided by an attachment. Moreover, the only reliable way to check is a key correct is to pass it to DbCrypt plugin and ask it to validate a key. That task can be performed only by CryptoManager code (only it has all required information about loaded plugins). KeyHolder plugin must just inform CryptoManager about a kind of provided key - should it be use only by own attachments or may be shared between attachments.
Submitted by: @AlexPeshkoff
Jira_subtask_inward CORE5472
Currently in case of SS architecture the first attachment which passed correct dbcrypt key works as unlocker for all further attachments - database key on SS is shared among all attachments using same DBB. In some cases (distributed encrypted databases) such behavior is highly undesired. Initially I've supposed that all functionality related with reject of key-less attachments may be implemented by KeyHolder plugin. Unfortunately such plugin in many cases can't efficiently distinguish between bad and correct key, provided by an attachment. Moreover, the only reliable way to check is a key correct is to pass it to DbCrypt plugin and ask it to validate a key. That task can be performed only by CryptoManager code (only it has all required information about loaded plugins). KeyHolder plugin must just inform CryptoManager about a kind of provided key - should it be use only by own attachments or may be shared between attachments.
Commits: ef2fbab e722a40
The text was updated successfully, but these errors were encountered: