In our current setup things like the key-auto-import folder are in a seperate git submodule only the repo admin can write to to prevent users from injection arbitrary keys but this does not prevent any existing key to be authorized by adding its id to a gpg-id file. While this is rather easy to notice by monitoring the repository activity, it is not prevented from happening in the first place.
Introducing an user promt to accept new keys might prove usefull with security aware users but will ultimately train regular users to just click accept.
With gpg signing a repository master key could be added to the local configuration either manually or on clone (in a subfolder which could be a submodule with seperate write permissions) which when present would cause keyswarm to reject any gpg-id files, public keys and repositoty configs not signed by a key signed by the repository master key.
In our current setup things like the key-auto-import folder are in a seperate git submodule only the repo admin can write to to prevent users from injection arbitrary keys but this does not prevent any existing key to be authorized by adding its id to a gpg-id file. While this is rather easy to notice by monitoring the repository activity, it is not prevented from happening in the first place.
Introducing an user promt to accept new keys might prove usefull with security aware users but will ultimately train regular users to just click accept.
With gpg signing a repository master key could be added to the local configuration either manually or on clone (in a subfolder which could be a submodule with seperate write permissions) which when present would cause keyswarm to reject any gpg-id files, public keys and repositoty configs not signed by a key signed by the repository master key.