Stephen, Joan,
Thanks for the pointers, but could you save me some time and explain how they
implement "security" so folks can't run bitcoin miners via the PRs?
Thanks,
-Alex
On 1/7/19, 7:54 AM, "Joan Touzet" <woh...@apache.org> wrote:
See travis-ci.org.
This is the model we could be emulating.
----- Original Message -----
From: "Alex Harui" <aha...@adobe.com.INVALID>
To: builds@apache.org
Sent: Sunday, January 6, 2019 6:53:44 PM
Subject: Re: PRJenkins builds for Projects
What other organizations are running a similar patch/pr Jenkins capability
and how do they implement "security" to prevent exploits like bitcoin miners
and other attacks?
IMO, if you give free compute resources, the bad people will eventually
figure out how to use it to their advantage.
-Alex
On 1/6/19, 10:52 AM, "Allen Wittenauer"
<a...@effectivemachines.com.INVALID> wrote:
> On Jan 6, 2019, at 10:43 AM, Dominik Psenner <dpsen...@gmail.com>
wrote:
>
> On Sun, Jan 6, 2019, 19:32 Allen Wittenauer
> <a...@effectivemachines.com.invalid wrote:
>
>>
>> a) The ASF has been running untrusted code since before Github
existed.
>> From my casual watching of Jenkins, most of the change code we run
doesn’t
>> come from Github PRs. Any solution absolutely needs to consider what
>> happens in a JIRA-based patch file world. [footnote 1,2]
>>
>
> If some project build begins to draw resources in an extraordinary
fashion
> it will be noticed.
Strongly disagree. My cleaner code killed three stuck surefire
jobs that had been looping on a handful of cores since sometime in 2018
yesterday. The sling jobs I noted earlier in the week had 20GB of RAM.
That’s even before we get into the unit-tests-that-are-really-integration-tests
that are coming from the big data projects where gigs of memory and thousands
of process slots are consumed on a regular basis.
