2009/8/12 Jeff Mitchell <mitch...@kde.org>: > 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.
If you sent the information via HTTPS then you would have verifaction that you're talking to the correct server for free. > 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 _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest