Skip to content

[18.0][ADD] vault_custodian: mandatory vault custodians - #998

Open
jans23 wants to merge 1 commit into
OCA:18.0from
Nitrokey:18.0-add-vault_custodian
Open

[18.0][ADD] vault_custodian: mandatory vault custodians#998
jans23 wants to merge 1 commit into
OCA:18.0from
Nitrokey:18.0-add-vault_custodian

Conversation

@jans23

@jans23 jans23 commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Adds a company setting 'Mandatory Custodians' listing users that are automatically added to every newly created vault with read + share permissions. These custodian rights can not be removed and their share permission can not be revoked, ensuring administrators/custodians retain access to e2e-encrypted vaults (e.g. when an employee leaves).

@jans23 jans23 changed the title [ADD] vault_custodian: mandatory vault custodians [18.0][ADD] vault_custodian: mandatory vault custodians Sep 2, 2026
@OSevangelist

OSevangelist commented Sep 2, 2026

Copy link
Copy Markdown

@jans23 @fkantelberg @pedrobaeza i think this additional module is really the right way to implement the requirement. So thanks. In order to make EVERYBODY aware of the decisions at stake, wouldn't it be valuable to outline a concrete practical use case (of that additional module) and a note on the major downsides (i.e. attack surface, theoretical misuse) of using this additional module to allow somebody using vault to take absolutely informed decisions on using vault_custodian as well. I think two sentences in the Readme should be sufficient. This should even valuable (if not mandatory) with respect to the upcoming Cyber Resilience Act (and all its adhering rules / regulations). What do you think?

@jans23

jans23 commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

Isn't this already described in the README? Feel free to propose a text change.

@OSevangelist

Copy link
Copy Markdown

@jans23 well the use case is indeed sufficiently described. I would (if you agree, please add it right away) add the following hint:

HINT: Please be aware that using this module will increase the attack surface of your instance and may be misused after all. Although the introduction of custodians is often practiced in industry environments (e.g. also Github allows that to gain access to repositories under certain conditions) the underlying business requirement may also be solved by organizing and enforcing processes in a non-technical manner.

@OSevangelist

Copy link
Copy Markdown

If you don't like it feel free to adapt but this should make it perfectly clear that the decision is a trade of between process efficiency (in favor of vault_custodian) or security (against the use of vault_custodian) @jans23

@jans23
jans23 force-pushed the 18.0-add-vault_custodian branch from b6ed382 to eae3a5b Compare September 2, 2026 15:29
@jans23

jans23 commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

I added two such sentences. Let me know if you suggest more changes.

Adds a company setting 'Mandatory Custodians' listing users that are
automatically added to every newly created vault with read + share
permissions. These custodian rights can not be removed and their
share permission can not be revoked, ensuring administrators/custodians
retain access to e2e-encrypted vaults (e.g. when an employee leaves).
@jans23
jans23 force-pushed the 18.0-add-vault_custodian branch from eae3a5b to 6952150 Compare September 8, 2026 19:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants