Hi Chris, Thank you for providing Carlos with instructions. Was that on or off list?
Regards, Dave Sent from my iPhone > On Jan 7, 2019, at 1:18 PM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > > Hi Alex, > > Ways to do bad stuff with just a pom.xml: > - simply adding a dependency to a vulnerable library, even an intentionally > staged malicious one. > - Adding an evec-maven-plugin to execute anything on the host machine > - Generate code > - Like I introduced into the FlexJS maven build: Patch/Modify source files > Guess the is what I could think of in 5 minutes... > > Ways to do bad stuff by just changing one-line versions: > And changing the version of a dependency to a known vulnerable version would > be such a one-liner. > I'm currently introducing vulnerability checks into all of my builds, so I'm > bumping dependencies to unvulnerable versions ... > doing this the other way around would introduce vulnerabilities. > > Connectivity problems: > Regarding network problems ... on my way to Montreal I staged the first RC > for Apache PLC4X in a plane ... > it took about 3 hours to upload cause of network problems and latencies. > Maven usually works around connectivity problems quite nicely and reliably. > > So all in all I would suggest you sort out the problems in the build with > someone with experience. > I already told Carlos how he could deploy to a local directory during the > release itself and then use another > plugin to stage that release independently. > If it aborts, you just re-start the deployment and close the repo as soon as > all passes. > > Chris > > > > Am 07.01.19, 19:39 schrieb "Alex Harui" <aha...@adobe.com.INVALID>: > > Hi Greg, > > Thanks for the history. I agree with the general problem, however, for > Royale, I think the problem is constrained, but I could be wrong. I don't > think there are exploits from things like missing semicolons and other code > exploits that can be executed against pom.xml files, so the Royale reviewers > are first looking to see if bot changed any other files. Maybe Maven experts > can tell us what kinds of exploit could be hacked into a pom.xml. > > Could you answer another question? What is the current state of SVN/Git > integration? Could we spin up an SVN clone of our Git repos, restrict the > bot via SVN, then sync back from SVN to Git (all from Jenkins)? > > Thanks, > -Alex > > On 1/7/19, 10:30 AM, "Greg Stein" <gst...@gmail.com> wrote: > > On Mon, Jan 7, 2019 at 12:23 PM Alex Harui <aha...@adobe.com.invalid> > wrote: >> ... > >> I still don't get why allowing a bot to commit to a Git repo isn't >> auditable. The changes should all be text and sent to commits@ and the >> RMs job is to verify that those commits are ok before putting the artifacts >> up for vote. I'd even try to make an email rule that checks for commits >> from buildbot and flags changes to files that are outside of what we >> expected. >> > > The historic position of the Foundation is "no ability to commit > without a > matched ICLA". That is different from "we'll audit any commits made by > $bot". The trust meter is rather different between those positions, > specifically with the "what if nobody reviews? what if a commit is > missed? > what if that added semicolon is missed, yet opens a vuln?" ... With the > "matched ICLA" position, the Foundation has the assurance of *that* > committer, that everything is Good. ... Yet a bot cannot make any such > assurances, despite any "best effort" of the PMC to review the bot's > work. > > It is likely a solvable problem! My comments here are to outline > history/policy, rather than to say "NO". These are just the parameters > of > the problem space. > > Cheers, > -g > InfraAdmin > > > >
