Re: automatic patch validation on TC

[dsetrakyan]

On Wed, May 20, 2015 at 6:26 AM, Yakov Zhdanov <[hidden email]>
wrote:

> I still insist that this should be implemented with great care.
>

I tend to agree with Cos here. Let's implement this feature. If we get some
malicious contributor attaching bad patches, we will catch it very quickly
and remove him/her from Jira. All it takes to catch something like this is
a normal patch review by a committer, which is part of Ignite standard
development process.


>
> 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.
>

Again, don't think it is an issue.

>
> > 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.
>

And again, if something bad happens, we can deal with it in a normal
fashion.

I personally think that we are worrying about something that will never
happen. My preference is to get this feature out as soon as possible so our
contributors have a normal path to execute builds on TeamCity.

D.

[Artem Shutak]

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.

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.

Thoughts?

-- Artem --

On Wed, May 20, 2015 at 4:26 PM, Yakov Zhdanov <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]>:
> > > > >
> > > > > > 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 <[hidden email]>:
> > > > > > >
> > > > > > > > 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 <
> > > > > > [hidden email]>
> > > > > > > > >    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
> > > > > > > > >      <[hidden email]>
> > > > > > > > >      >A  A  wrote:
> > > > > >
> > > >
> > > >
> >
>

[Konstantin Boudnik-2]

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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>:
> > > >
> > > > > 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 <[hidden email]>:
> > > > > >
> > > > > > > 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 <[hidden email]>:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > > > [hidden email]>
> > > > > > > > > >    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
> > > > > > > > > >      <[hidden email]>
> > > > > > > > > >      >A  A  wrote:
> > > > > > >
> > > > >
> > > > >
> > >
> >

[Branko Čibej]

On 20.05.2015 21:36, Dmitriy Setrakyan wrote:

> On Wed, May 20, 2015 at 6:26 AM, Yakov Zhdanov <[hidden email]>
> wrote:
>
>> I still insist that this should be implemented with great care.
>>
> I tend to agree with Cos here. Let's implement this feature. If we get some
> malicious contributor attaching bad patches, we will catch it very quickly
> and remove him/her from Jira. All it takes to catch something like this is
> a normal patch review by a committer, which is part of Ignite standard
> development process.

Exactly. This is one of the reasons why we make our repository, Jira,
commit notifications etc. public. Any number of projects have automatic
patch validation, and I've yet to hear about a single attack or exploit
that got in through that channel.

-- Brane

[Artem Shutak]

Hi, Cos,

I cannot agree with you.

I rechecked it again. What I did:
1. Sign up with new user to Apache Jira (
https://issues.apache.org/jira/secure/Signup!default.jspa). // I didn't add
any privileges.
2. Open https://issues.apache.org/jira/browse/IGNITE-456
3. Add txt and patch - files to the issue. You can see at history of the
issue (see attachments by tc_commenter).

Please, recheck it for ignite-ci and let me know if you cannot attach files
by this user.

-- Artem --

On Thu, May 21, 2015 at 12:57 AM, Konstantin Boudnik <[hidden email]> wrote:

> 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]>:
> > > > >
> > > > > > 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 <[hidden email]
> >:
> > > > > > >
> > > > > > > > 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 <
> [hidden email]>:
> > > > > > > > >
> > > > > > > > > > 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
> <
> > > > > > > > [hidden email]>
> > > > > > > > > > >    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
> > > > > > > > > > >      <[hidden email]>
> > > > > > > > > > >      >A  A  wrote:
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > >
>

[dsetrakyan]

Are we saying that non-contributors can attach patches?

On Thu, May 21, 2015 at 2:24 AM, Artiom Shutak <[hidden email]> wrote:

> Hi, Cos,
>
> I cannot agree with you.
>
> I rechecked it again. What I did:
> 1. Sign up with new user to Apache Jira (
> https://issues.apache.org/jira/secure/Signup!default.jspa). // I didn't
> add
> any privileges.
> 2. Open https://issues.apache.org/jira/browse/IGNITE-456
> 3. Add txt and patch - files to the issue. You can see at history of the
> issue (see attachments by tc_commenter).
>
> Please, recheck it for ignite-ci and let me know if you cannot attach files
> by this user.
>
> -- Artem --
>
> On Thu, May 21, 2015 at 12:57 AM, Konstantin Boudnik <[hidden email]>
> wrote:
>
> > 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 <[hidden email]>
> > > 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 <[hidden email]>:
> > > >
> > > > > 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 <[hidden email]>:
> > > > > >
> > > > > > > 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 <
> [hidden email]
> > >:
> > > > > > > >
> > > > > > > > > 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 <
> > [hidden email]>:
> > > > > > > > > >
> > > > > > > > > > > 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
> > <
> > > > > > > > > [hidden email]>
> > > > > > > > > > > >    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
> > > > > > > > > > > >      <[hidden email]>
> > > > > > > > > > > >      >A  A  wrote:
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > >
> >
>

[Branko Čibej]

On 21.05.2015 11:35, Dmitriy Setrakyan wrote:
> Are we saying that non-contributors can attach patches?


Slow down. Anyone who sends a patch is, by definition, a contributor.
Whether or not you decide to use the patch is a different matter. You
don't want to invent any extremely paranoid access control; that's
contrary to the whole point of open source.

If you don't want to automatically test patches in your test
environment, then by all means don't do that. You can invent a 'patch
reviewed' state in Jira that needs explicit permission to be set, and
only send the patch to CI once a committer has reviewed the patch.

-- Brane

[dsetrakyan]

On Thu, May 21, 2015 at 2:48 AM, Branko Čibej <[hidden email]> wrote:

> On 21.05.2015 11:35, Dmitriy Setrakyan wrote:
> > Are we saying that non-contributors can attach patches?
>
>
> Slow down. Anyone who sends a patch is, by definition, a contributor.
> Whether or not you decide to use the patch is a different matter. You
> don't want to invent any extremely paranoid access control; that's
> contrary to the whole point of open source.
>

Brane, as far as I know, in order for someone to start working on a ticket
we need to add him/her to the list of "contributors" in Jira. Otherwise the
ticket cannot even be assigned to that person. I thought that only the
people on the Jira "contributor" list can attach patches. Is this not so?
If not, can we configure Jira to work in that way?



>
> If you don't want to automatically test patches in your test
> environment, then by all means don't do that. You can invent a 'patch
> reviewed' state in Jira that needs explicit permission to be set, and
> only send the patch to CI once a committer has reviewed the patch.
>
> -- Brane
>
>

[Branko Čibej]

On 21.05.2015 12:00, Dmitriy Setrakyan wrote:

> On Thu, May 21, 2015 at 2:48 AM, Branko Čibej <[hidden email]> wrote:
>
>> On 21.05.2015 11:35, Dmitriy Setrakyan wrote:
>>> Are we saying that non-contributors can attach patches?
>>
>> Slow down. Anyone who sends a patch is, by definition, a contributor.
>> Whether or not you decide to use the patch is a different matter. You
>> don't want to invent any extremely paranoid access control; that's
>> contrary to the whole point of open source.
>>
> Brane, as far as I know, in order for someone to start working on a ticket
> we need to add him/her to the list of "contributors" in Jira. Otherwise the
> ticket cannot even be assigned to that person. I thought that only the
> people on the Jira "contributor" list can attach patches. Is this not so?
> If not, can we configure Jira to work in that way?

I don't know how ASF Jira is set up, but surely people can create new
tickets and attach patches to them?

-- Brane

[Artem Shutak]

I think I found good way to resolve any security issues here. We will use
attachments only from approved users list (contributors).

Objections?

-- Artem --

On Thu, May 21, 2015 at 1:13 PM, Branko Čibej <[hidden email]> wrote:

> On 21.05.2015 12:00, Dmitriy Setrakyan wrote:
> > On Thu, May 21, 2015 at 2:48 AM, Branko Čibej <[hidden email]> wrote:
> >
> >> On 21.05.2015 11:35, Dmitriy Setrakyan wrote:
> >>> Are we saying that non-contributors can attach patches?
> >>
> >> Slow down. Anyone who sends a patch is, by definition, a contributor.
> >> Whether or not you decide to use the patch is a different matter. You
> >> don't want to invent any extremely paranoid access control; that's
> >> contrary to the whole point of open source.
> >>
> > Brane, as far as I know, in order for someone to start working on a
> ticket
> > we need to add him/her to the list of "contributors" in Jira. Otherwise
> the
> > ticket cannot even be assigned to that person. I thought that only the
> > people on the Jira "contributor" list can attach patches. Is this not so?
> > If not, can we configure Jira to work in that way?
>
> I don't know how ASF Jira is set up, but surely people can create new
> tickets and attach patches to them?
>
> -- Brane
>
>

[Konstantin Boudnik-2]

Can anyone with project admin rights check the permissions chema and see
if there's a tweak for 'Patch available' for different roles in the
    project? i think there is, but i'm on vacation, really.

Thanks,
  Cos
   
On Thu, May 21, 2015 at 04:30PM, Artiom Shutak wrote:

> I think I found good way to resolve any security issues here. We will use
> attachments only from approved users list (contributors).
>
> Objections?
>
> -- Artem --
>
> On Thu, May 21, 2015 at 1:13 PM, Branko Čibej <[hidden email]> wrote:
>
> > On 21.05.2015 12:00, Dmitriy Setrakyan wrote:
> > > On Thu, May 21, 2015 at 2:48 AM, Branko Čibej <[hidden email]> wrote:
> > >
> > >> On 21.05.2015 11:35, Dmitriy Setrakyan wrote:
> > >>> Are we saying that non-contributors can attach patches?
> > >>
> > >> Slow down. Anyone who sends a patch is, by definition, a contributor.
> > >> Whether or not you decide to use the patch is a different matter. You
> > >> don't want to invent any extremely paranoid access control; that's
> > >> contrary to the whole point of open source.
> > >>
> > > Brane, as far as I know, in order for someone to start working on a
> > ticket
> > > we need to add him/her to the list of "contributors" in Jira. Otherwise
> > the
> > > ticket cannot even be assigned to that person. I thought that only the
> > > people on the Jira "contributor" list can attach patches. Is this not so?
> > > If not, can we configure Jira to work in that way?
> >
> > I don't know how ASF Jira is set up, but surely people can create new
> > tickets and attach patches to them?
> >
> > -- Brane
> >
> >

[dsetrakyan]

On Thu, May 21, 2015 at 10:27 AM, Konstantin Boudnik <[hidden email]> wrote:

> Can anyone with project admin rights check the permissions chema and see
> if there's a tweak for 'Patch available' for different roles in the
> project? i think there is, but i'm on vacation, really.
>

Cos, vacation is hardly an excuse :) Get back to work!

[Konstantin Boudnik-2]

On Thu, May 21, 2015 at 10:32AM, Dmitriy Setrakyan wrote:
> On Thu, May 21, 2015 at 10:27 AM, Konstantin Boudnik <[hidden email]> wrote:
>
> > Can anyone with project admin rights check the permissions chema and see
> > if there's a tweak for 'Patch available' for different roles in the
> > project? i think there is, but i'm on vacation, really.
> >
>
> Cos, vacation is hardly an excuse :) Get back to work!

I don't think so.