Johan, Had a discussion with some KDE people and had a few thoughts regarding possible access control/hook solutions:
1) You don't want to allow arbitrary shell scripts -- but might there be a way to allow sanitized text with specific wording, or entered into a specific UI in the webapp, such that pre-commit and post-commit hooks could be used? A specific issue we have is a repository that is currently svn-externed into kdelibs but that we cannot allow arbitrary write access to for any kdelib developer. That way we could possibly have specific data values that could be converted on the back-end to a pre-commit hook so that we can limit write access to a particular path. We don't really want to put it in another repo and use a git submodule because that creates a burden on everyone cloning the repo. 2) I was thinking about how you were talking about sending out commit information via HTTP. If we set up pub/pri key pairs, could something like the following be done: in a pre-commit hook, you send out information via HTTP, with a secret encrypted with a public key and a callback URL. The server you send it to runs a script to validate things -- for instance, person X has authorization to commit to path Y -- and sends back either an approve or reject message, along with the decrypted contents of the secret for verification. Then the commit is allowed or denied based on this. This would allow us to do arbitrary processing with the commit data and not have to put that processing on your machines. Thanks, Jeff
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest