From: "H. Peter Anvin" <hpa@zytor.com>
To: Konstantin Ryabitsev <mricon@kernel.org>, josh@joshtriplett.org
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TOPIC] Services needed from kernel.org
Date: Wed, 21 May 2014 10:17:24 -0700 [thread overview]
Message-ID: <537CDFA4.3030400@zytor.com> (raw)
In-Reply-To: <537BF61A.5010700@kernel.org>
On 05/20/2014 05:40 PM, Konstantin Ryabitsev wrote:
> On 20/05/14 06:53 PM, josh@joshtriplett.org wrote:
>> How feasible is it to support git hooks that want to construct
>> and send (significant volumes of) email, while retaining the
>> security and sandboxing currently being applied to git
>> repositories?
>
> It's feasible, but I can't make this a free-for-all, for obvious
> reasons. :) With gitolite, hooks execute as the same user "git"
> and therefore any code running inside a hook has unfettered access
> to all git repositories regardless of in-gitolite repository
> permissions.
>
> What we can do is have a peer-reviewed collection of "blessed"
> hooks available to developers. Not being a kernel dev myself, I'm
> not the one to put such a collection together, though -- I'm not
> even sure if such a cookie-cutter approach would be suitable.
>
> I guess what I'm really trying to say is that I'd rather avoid
> having to continuously review code written by people to whom "you
> write perl like it's C" is a compliment. ;) If we can get by with a
> handful of standard hooks, I'm for it, though.
>
Hmm... I resemble that remark.
That being said, there is no fundamental reason that email generator
have to be run on the master copy. It can be run on an entirely
different box, which doesn't even need any kind of privileged access
to the machinery; this is how the tip-bot runs: it is just a "regular
puller" of the tip tree, using the publicly accessible git port. This
does add some latency, but has the advantage that it sends out the
emails once the commits are actually visible to general users upstream.
Generalizing the tip-bot is probably not that hard. I already use
variants of it for multiple projects. It does have a *lot* of
configuration options, though, some of which are in the form of
scripts. This pretty much means that in its current form it is
equivalent to a shell account and would have to be sandboxed accordingly.
-hpa
next prev parent reply other threads:[~2014-05-21 17:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-20 18:48 H. Peter Anvin
2014-05-20 22:53 ` josh
2014-05-20 23:28 ` James Bottomley
2014-05-20 23:46 ` Jiri Kosina
2014-05-21 0:40 ` Konstantin Ryabitsev
2014-05-21 17:17 ` H. Peter Anvin [this message]
2014-05-21 17:37 ` Andy Lutomirski
2014-05-21 18:12 ` Josh Triplett
2014-05-21 15:18 ` David Howells
2014-05-21 16:15 ` Konstantin Ryabitsev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=537CDFA4.3030400@zytor.com \
--to=hpa@zytor.com \
--cc=josh@joshtriplett.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=mricon@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox