impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Apple <jbap...@cloudera.com>
Subject Re: Jenkins jobs to verify patches
Date Wed, 14 Dec 2016 22:00:19 GMT
I do not understand the proposed security benefit of using github for
user authentication over using Jenkins permissions directly. Keep in
mind that preventing non-+2ed commits from being run is an orthogonal
question - this can be configured with any user authentication method.

On Wed, Dec 14, 2016 at 1:52 PM, Bharath Vissapragada
<bharathv@cloudera.com> wrote:
> That was just for configuring the gerrit trigger. Regarding auth
> integration, I read this page. Does it not work?
>
> https://wiki.jenkins-ci.org/display/JENKINS/GitHub+OAuth+Plugin#GitHubOAuthPlugin-AboutGitHubAuthenticationPlugin
>
> On Wed, Dec 14, 2016 at 1:50 PM, Jim Apple <jbapple@cloudera.com> wrote:
>
>> I think you're misunderstanding that plugin. It does not associate
>> Jenkins login with gerrit login.
>>
>> On Wed, Dec 14, 2016 at 1:45 PM, Bharath Vissapragada
>> <bharathv@cloudera.com> wrote:
>> > On Wed, Dec 14, 2016 at 1:38 PM, Alex Behm <alex.behm@cloudera.com>
>> wrote:
>> >
>> >> That integration sounds like a great idea to me.
>> >>
>> >> Just to clarify the purpose: We'd like external contributors to be able
>> to
>> >> run private build+test runs during development, and not just run GVO
>> once
>> >> the patch has +2. The hard part is gettig the patch to +2 in the first
>> >> place and we've seen instances where relying on local test runs only
>> can be
>> >> difficult.
>> >>
>> >> For example, contributors could upload a draft to gerrit and run a
>> private
>> >> build to fix problems before publishing the patch fir review.
>> >>
>> >
>> > As per this [1] link, I think that can be configured. I haven't tried it
>> > myself, but from the looks of it, it seems plausible.
>> >
>> > [1]
>> > https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+
>> Trigger#GerritTrigger-TriggerConfiguration
>> >
>> >
>> >>
>> >> On Wed, Dec 14, 2016 at 1:33 PM, Bharath Vissapragada <
>> >> bharathv@cloudera.com
>> >> > wrote:
>> >>
>> >> > Just wondering why we can't link Jenkins authentication with gerrit
>> login
>> >> > in this case instead of having two separate login credentials. That
>> way
>> >> we
>> >> > can retain the audit trail of the jobs and also isolate Jenkins to
>> only
>> >> run
>> >> > code thats approved (+2ed) over gerrit. With this, any new contributor
>> >> > (whoever has signed up on gerrit) can have access to the jenkins box
>> and
>> >> we
>> >> > can be sure that they only run the stuff that is approved by
>> committers.
>> >> > Thoughts?
>> >> >
>> >> > * I'm not totally sure if such an integration is possible but I did
a
>> >> quick
>> >> > search and I got a feeling that shouldn't be difficult.
>> >> >
>> >> > On Wed, Dec 14, 2016 at 1:18 PM, Taras Bobrovytsky <
>> >> > tbobrovytsky@cloudera.com> wrote:
>> >> >
>> >> > > I would be more in favor of starting with open access instead
of
>> having
>> >> > to
>> >> > > hand out credentials. It's both less work for us and it makes
it
>> easier
>> >> > to
>> >> > > contribute. If we notice that this is not working well, or gets
>> abused,
>> >> > we
>> >> > > can switch to what Tim is suggesting. Also, we should be able
to see
>> >> who
>> >> > is
>> >> > > using our Jenkins by looking at Gerrit (because the patch must
be
>> >> > uploaded
>> >> > > to Gerrit before starting a build).
>> >> > >
>> >> > > On Wed, Dec 14, 2016 at 10:57 AM, Alex Behm <alex.behm@cloudera.com
>> >
>> >> > > wrote:
>> >> > >
>> >> > > > I'm fine with Tim's approach, but it does add some friction
to
>> >> > > > contributions.
>> >> > > >
>> >> > > > On Wed, Dec 14, 2016 at 9:57 AM, Tim Armstrong <
>> >> > tarmstrong@cloudera.com>
>> >> > > > wrote:
>> >> > > >
>> >> > > > > I mean the contributor could email an email address
(e.g. a
>> mailing
>> >> > > list)
>> >> > > > > asking for credentials and we could email them privately.
>> >> > > > >
>> >> > > > > Do we know what other Apache projects do for situations
like
>> this?
>> >> > > > >
>> >> > > > > On Wed, Dec 14, 2016 at 9:18 AM, Alex Behm <
>> alex.behm@cloudera.com
>> >> >
>> >> > > > wrote:
>> >> > > > >
>> >> > > > > > Can you clarify the "credentials by mailing list"
approach?
>> >> > > > > >
>> >> > > > > > If we send out the credentials on a public list,
it's pretty
>> >> close
>> >> > to
>> >> > > > > open
>> >> > > > > > access.
>> >> > > > > >
>> >> > > > > > If we send out credentials to contributors privately,
we have
>> an
>> >> > > > > additional
>> >> > > > > > hurdle to contributions.
>> >> > > > > >
>> >> > > > > > On Wed, Dec 14, 2016 at 9:12 AM, Tim Armstrong
<
>> >> > > > tarmstrong@cloudera.com>
>> >> > > > > > wrote:
>> >> > > > > >
>> >> > > > > > > Got it.
>> >> > > > > > >
>> >> > > > > > > I think I'd probably be more in favour of
handing out login
>> >> > > > credential
>> >> > > > > to
>> >> > > > > > > contributors on demand (e.g. by mailing a
list)  rather than
>> >> > having
>> >> > > > > open
>> >> > > > > > > access, just so we have a clearer idea of
who's using it. I
>> >> don't
>> >> > > > have
>> >> > > > > a
>> >> > > > > > > strong objection to the alternative.
>> >> > > > > > >
>> >> > > > > > > On Wed, Dec 14, 2016 at 8:52 AM, Jim Apple
<
>> >> jbapple@cloudera.com
>> >> > >
>> >> > > > > wrote:
>> >> > > > > > >
>> >> > > > > > > > > How isolated is the Jenkins instance?
>> >> > > > > > > >
>> >> > > > > > > > As far as I know, the workers have little
access to the
>> >> > > > coordinator.
>> >> > > > > > See
>> >> > > > > > > > here:
>> >> > > > > > > >
>> >> > > > > > > > https://wiki.jenkins-ci.org/display/JENKINS/Slave+To+
>> >> > > > > > > Master+Access+Control
>> >> > > > > > > >
>> >> > > > > > > > This flag is on and there are no whitelisted
exceptions.
>> >> > > > > > > >
>> >> > > > > > > > > Does the jenkins user have many
privileges on the VM?
>> >> > > > > > > >
>> >> > > > > > > > They have passwordless sudo on the worker
>> >> > > > > > > >
>> >> > > > > > > > > Could it simply wipe
>> >> > > > > > > > > out the job history to destroy the
trail?
>> >> > > > > > > >
>> >> > > > > > > > Job history is stored on the coordinator.
>> >> > > > > > > >
>> >> > > > > > > > > Jenkins also presumably has
>> >> > > > > > > > > credentials to make at least some
changes to gerrit -
>> are
>> >> > those
>> >> > > > > > > > privileges
>> >> > > > > > > > > restrictive enough that it couldn't
cause problems there
>> >> too?
>> >> > > > > > > >
>> >> > > > > > > > Those are stored only on the coordinator
and cannot be
>> used
>> >> by
>> >> > > the
>> >> > > > > > > slaves.
>> >> > > > > > > >
>> >> > > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>

Mime
View raw message