On 2019/01/08 17:47:28, Joan Touzet <woh...@apache.org> wrote:
> Alex:
>
> A short list, not comprehensive:
>
> 0) Bitcoin mining is against the Travis CI ToS.
> https://docs.travis-ci.com/legal/terms-of-service/
> 1) There are maximum job run times in Travis that prevent unbounded
> compute, regardless of technology.
> 2) Travis blacklist a bunch of IPs.
> 3) Travis have some proprietary heuristics that look for and kill
> bitcoin mining jobs
> 4) Travis can be configured to only run builds on specific branches,
> i.e. the build only runs against your master branch, or you can
> have the run only run with the proposed merge of the PR into the
> master branch.
> 4) There is always human review involved at some point.
>
> As for uploading built artifacts automatically:
>
> https://docs.travis-ci.com/user/uploading-artifacts/
>
> And doing commits:
>
>
> https://stackoverflow.com/questions/42253765/getting-travisci-to-commit-and-push-a-modified-file-with-tags-releases#42299765
>
> Encrypting credentials:
>
> https://docs.travis-ci.com/user/encryption-keys/
>
> "Please note that encrypted environment variables are not available for pull
> requests from forks."
>
> It's this last point that prevents unauthorized contributors (i.e.,
> the general public we wring our hands about) from using your encrypted
> credentials to do whatever. Anyone who has write access to the repo
> already (i.e., CLA-signed committers) and makes their branch on the
> repo itself would have access - but if you don't trust your committers,
> who can you trust?
>
> I believe this is the missing piece for Jenkins CI.
Nope. Though configuring the behaviour for untrusted refs is a bit of a dark
magic. For one the Authorize Project plugin was implemented without anyone
paying attention to the permissions stuff in the Credentials plugin... so there
are some minor pitfalls there... mostly around people not actually
understanding what the different credentials stores are for. Then the SCM API
trusted refs stuff is poorly understood... and finally on top of all that
Pipeline currently runs the Groovy script on the master so you cannot verify
untrusted refs that change the Jenkinsfile while having the security
protections.
But you can most certainly set up Jenkins to have access to a user's deployment
credentials when triggered by the user wanting to deploy while preventing PRs
from accessing those credentials... However it probably requires a Jenkins
Ninja such as myself, KK, Jesse or Oleg to set it up!
New initiatives in Jenkins will help make these things accessible to people not
intimately aware of the finer details of how Jenkins works
>
> -Joan
>
> ----- Original Message -----
> > From: "Alex Harui" <aha...@adobe.com>
> > To: builds@apache.org, woh...@apache.org
> > Sent: Monday, January 7, 2019 1:06:27 PM
> > Subject: Re: PRJenkins builds for Projects
> >
> > 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.
> >
> >
> >
>
