> On Jan 6, 2019, at 1:18 PM, Stephen Connolly <steph...@apache.org> wrote:
>
>
>
> On 2019/01/06 18:32:24, 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]
>
> There is a big difference between things like JIRA patches and pull requests
> on GitHub.
>
> A pull request from GitHub *can* be checked out correctly without human
> intervention. Patch files require knowing the exact base and how much of the
> prefix to strip off.
It’s not a hard problem. We’ve been running automated JIRA-based patch
file pipelines forever. Here’s an early version (if not the first official one):
https://github.com/apache/hadoop/blob/e3337dc9b0b274e5f6318fb0fe64d49f57df0c9a/src/test/bin/test-patch.sh
(Latest version of that code is way better and now part of Apache Yetus)
So, again, focusing on GitHub PR-based solutions covers only a small
fraction of the current Jenkins workloads, especially given the majority (at
least today) are driven from JIRA…
> Further, the ASF does not control GitHub signups (a good thing for growing
> the community, but it produces a consequent lower level of assumed trust)
Anyone can create an account on the ASF’s JIRA instance. I believe the
submit patch button was locked down in the past year or two. Thanks to the
asfgit JIRA<->Github cross-pollination hooks though, it’s possible to just add
a comment that points to an GitHub PR and have it get processed. So submit
patch isn’t required.
> I have seen GitHub PRs against other public repos where there have been
> drive-by bitcoin mining by modifying a unit test to run the miner. (And
> that's just the attack vectors that are public and hence safe to disclose)
>
> The GitHub PR is a potent attack vector (which is why Jenkins provides some
> tools to help... the tools could be better, but my day job has me focused on
> non Jenkins stuff right now... I haven't been paid to work on Jenkins stuff
> for 18 months)
"the tools could be better” … Umm, very big understatement. Jenkins
has some huge design flaws that will likely never get fixed due to
compatibility issues or, frankly, Cloudbees acknowledging there are even
problems. [He says, having spent most of the morning fighting against missing
features and bugs in Pipeline code. Freestyle is still, in many ways, more
powerful.]
