ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: Fwd: automatic patch validation on TC
Date Wed, 20 May 2015 21:57:01 GMT
There's user ignite-ci, that I created a while ago, but it isn't mandatory to
use it of course ;)

On Thu, May 21, 2015 at 12:23AM, Artiom Shutak wrote:
> I've created new Jira user without granting him some additional privileges.
> 
> The user cannot move jira status, but he can add any attachment under this
> user.
> 
> I see at least one bad scenario: hacker can just monitor for new "Patch
> available" tickets and attach a bad patch. As a result, the test builds
> will run with bad patch.

A hacker can not attach anything unless he has contributor's permissions.

> I think, for example, we should approve to attach files with "patch"
> extensions for contributors only (Somebody knows can we do that?), or just
> manually run all test builds for attached to TC file or link on file.

I am not sure what does it solve? Isn't that enough to impose limits on who
can attach/change JIRA state? 

Cos

> Thoughts?
> 
> -- Artem --
> 
> On Wed, May 20, 2015 at 4:26 PM, Yakov Zhdanov <yzhdanov@gridgain.com>
> wrote:
> 
> > I still insist that this should be implemented with great care.
> >
> > Cos, can you please provide information on which projects used same
> > approach?
> >
> > > Don't we trust our contributors?
> >
> > Well, you never know how they store the password and how strong it is.
> >
> > > if TC agents aren't running as privileged user - and they shouldn't be -
> >   malicious code won't do any harm to the system.
> >
> > Ignite tests should be able to do a lot of operations - establish network
> > connections, accept incoming connections, start processes and access file
> > system.
> >
> > In order to address possible issues we need to:
> > 1. limit the tests scenarios launched on patch attach.
> > 2. backup TC workers state once a day and store several days history to
> > quickly restore the state.
> >
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2015-05-19 20:53 GMT+03:00 Konstantin Boudnik <cos@apache.org>:
> >
> > > Here's two reasons why current approach is secure enough (and in fact has
> > > been used for some time on Apache build infrastructure):
> > >
> > > - only project contributors can manipulate JIRA: attaching, changing
> > >   state, etc. Don't we trust our contributors?
> > > - if TC agents aren't running as privileged user - and they shouldn't be
> > -
> > >   malicious code won't do any harm to the system.
> > >
> > > Thoughts?
> > >   Cos
> > >
> > > On Tue, May 19, 2015 at 04:47PM, Yakov Zhdanov wrote:
> > > > Guys,
> > > >
> > > > It seems we need to stop any activity in this direction.
> > > >
> > > > I have just realized that automatic patch validation (at least in its
> > > form
> > > > we agreed on) opens a huge security hole - anyone who attaches a patch
> > to
> > > > JIRA can execute literally any code (!) on our public TC -
> > > > java/bash/binary/built-in OS/etc. Should I continue on what this can
> > lead
> > > > to? I think no.
> > > >
> > > > So, the only acceptable way is to assign committer to review a patch
> > > > manually and then submit it to TC.
> > > >
> > > > Process in my view should be the following:
> > > >
> > > > 1. Contributor finishes with the task and attaches a patch to JIRA
> > issue.
> > > > 2. Committer picks up the issue and reviews the changes.
> > > > 3. If changes are OK, committer submits them to TC in a separate
> > branch.
> > > > 4. After TC passes committer merges the changes to the target sprint
> > > branch.
> > > > 5. JIRA issue gets closed.
> > > >
> > > > Thoughts?
> > > >
> > > > --Yakov
> > > >
> > > > 2015-05-05 23:31 GMT+03:00 Konstantin Boudnik <cos@apache.org>:
> > > >
> > > > > Sergey and I had a good Skype call and everything seems to be
> > > resolved. The
> > > > > installed jira-cli tools work just fine http://bit.ly/1c2qmeH
> > > > >
> > > > > Attachments and comments do not need to be fetched using jira-cli.
> > The
> > > > > proposed workflow for the automatic patching is explained at the
> > > bottom of
> > > > >     dev-tools/src/main/groovy/jiraslurp.groovy
> > > > > please let me know if there are any questions about it.
> > > > >
> > > > > Sergey will see to make sure that we have parameterized builds, which
> > > will
> > > > > be
> > > > > triggered from the groovy script above. In fact, that is the last
> > thing
> > > > > that
> > > > > is blocking the completion of this task. Looks like our off-line
> > > > > conversation
> > > > > with him helped to get the ball rolling!
> > > > >
> > > > > Cos
> > > > >
> > > > > On Wed, Apr 29, 2015 at 12:45PM, Yakov Zhdanov wrote:
> > > > > > Cos,
> > > > > >
> > > > > > Does cli works on your local machine?
> > > > > >
> > > > > > Can you check if our JIRA allows remote API calls -> "Go
to
> > > > > Administration
> > > > > > -> General Configuration and ensure Accept remote API calls
in ON"?
> > > > > >
> > > > > > Sergey tried it locally and it just hangs.
> > > > > >
> > > > > >
> > > > > > --Yakov
> > > > > >
> > > > > > 2015-04-28 20:30 GMT+03:00 Konstantin Boudnik <cos@apache.org>:
> > > > > >
> > > > > > > Hi Yakov.
> > > > > > >
> > > > > > > With jira-cli 3.9 one doesn't need to install anything
on the
> > > server
> > > > > side.
> > > > > > > The
> > > > > > > older version of the tools work with JIRA backend. The
newer
> > > version
> > > > > (not
> > > > > > > produced by Atlassian anymore) requires some additional
stuff to
> > be
> > > > > set.
> > > > > > >
> > > > > > > I will take a look at the agents' configuration later in
the day
> > > and
> > > > > will
> > > > > > > get
> > > > > > > back to you here.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >   Cos
> > > > > > >
> > > > > > > On Tue, Apr 28, 2015 at 01:40PM, Yakov Zhdanov wrote:
> > > > > > > > Cos,
> > > > > > > >
> > > > > > > > We still have problem while applying patch on TC.
Attachments
> > and
> > > > > > > comments
> > > > > > > > cannot be fetched from Jira when using jira-cli on
current
> > > agents.
> > > > > > > >
> > > > > > > > Can you please make sure that server side of jira-cli
is
> > properly
> > > > > > > > installed? Do you know any other way to fetch that?
> > > > > > > >
> > > > > > > > --Yakov
> > > > > > > >
> > > > > > > > 2015-04-01 6:23 GMT+03:00 Konstantin Boudnik <cos@apache.org>:
> > > > > > > >
> > > > > > > > > oops
> > > > > > > > >
> > > > > > > > >     s/not/now/g
> > > > > > > > >
> > > > > > > > > Cos
> > > > > > > > >
> > > > > > > > > On Tue, Mar 31, 2015 at 06:58PM, Dmitriy Setrakyan
wrote:
> > > > > > > > > >    On Tue, Mar 31, 2015 at 6:54 PM, Konstantin
Boudnik <
> > > > > > > cos@apache.org>
> > > > > > > > > >    wrote:
> > > > > > > > > >
> > > > > > > > > >      Thanks - that's great: not I'd be able
to finish up
> > the
> > > > > > > commenting
> > > > > > > > > part of the patch validation!
> > > > > > > > > >
> > > > > > > > > >    Cos, I think some meaning was lost due
to typos. Do you
> > > mean
> > > > > that
> > > > > > > you
> > > > > > > > > will
> > > > > > > > > >    be able to finish it or will not?
> > > > > > > > > >
> > > > > > > > > >      Cos
> > > > > > > > > >
> > > > > > > > > >      On Wed, Apr 01, 2015 at 12:00AM, Sergey
Bachinskiy
> > > wrote:
> > > > > > > > > >      >A  A  Hello Konstantin.
> > > > > > > > > >      >A  A  I've installed lira-cli on
all agents (7) -
> > path
> > > of
> > > > > cli
> > > > > > > is
> > > > > > > > > >      >A  A  /opt/jira-cli-3.9.0
> > > > > > > > > >      >A  A  On Wed, Mar 25, 2015 at 10:16
PM, Konstantin
> > > Boudnik
> > > > > > > > > >      <cos@apache.org>
> > > > > > > > > >      >A  A  wrote:
> > > > > > >
> > > > >
> > > > >
> > >
> >

Mime
View raw message